OpenXcom Forum

Modding => OpenXcom Extended => Topic started by: Yankes on September 07, 2014, 06:50:34 pm

Title: Old OXCE discussion thread
Post by: Yankes on September 07, 2014, 06:50:34 pm
Extended version of OpenXcom
Mod version 4.0a
OpenXcom date:   Nightly 2018-08-17
OpenXcom commit: a6d2d32495d9a2efa5b3460a284b7be33629129d
Extended date:   2018-09-09
Extended commit: 5fb565cd9d7b31978b4a152a38b55cd389b1ffb0


Ubuntu required libs
sudo apt-get install libsdl1.2debian libsdl-mixer1.2 libsdl-gfx1.2-4 libsdl-image1.2 libyaml-cpp0.5


Behavior change

Hyper-Wave Decoder can have less than 100% chance to detect aliens.
Explosions don't remove unconscious unit if they can't kill them first.
Craft weapon equip screen is a bit rearranged.
Fixed "weapons" like the Medikit are now equipped by unit.
Psi-Amp use 3d range, not 2d.
Psi-Amp can use weapon power.
Fixed ammo are added after weapons in armor and unit (armor items are before unit items).
Corpses, items and Chryssalids are not spawned when unit is killed by weapons with overkill.
Stunned units can be hited by bullets and fire.
Big groups of aliens (20+) get less morale losses from casualties.
Terror units can now spawn with any built-in weapon, not only one defined by name.
While loading and unloading weapons you must pay the cost of moving the item to hand.
You can unprime granade for half of prime TUs cost.
Support for Ufo2000 armor damage type.
Psi-Amp can now obey maximum weapon range.
Psi-Amp can now deal direct damage using special attack type in popup menu.
Throwing now requires a healthy arm to do it (if the item is two-handed, then it requires both).
You can hit aliens in the head using any item you like, not only firearms stock.
Items can now be non-throwable.
Rewriten handling of alien psi attacks to handle new features of Psi-Amp.
Building, manufactures and research can now have special requirements for buildings available in base.
Throwing and hitting using two-handed weapons have the same penalty as with shooting.

1.6:
You can train your solders basic skills.
Aliens weapon types/weapons can have different turn restriction.
You can rename weapon slot names in geoscape craft info.

1.7:
Rewritten item use cost. Now is possible to spend HP, Morale or grain stun damage from using items.
You can't use old `energy*` properties in item, they are removed and replaced by new one in `cost*`.
Item have now range threshold unit they start calculating range power reduction.
Damage type can now change default power change per tile in explosion.

1.8:
Option for custom weapon deploy for alien missions and ufos.

1.9:
Options for customizing retaliation mission after shooting dow ufo.
Options for adding custom dodge chance or unit psi defence.

2.0:
Breaking change: Psi-Amp use now weapon dropoff and aimRange for attack chance.
Breaking change: Drop support for Regeneration stat in armor. Use new regen stats now.
Inventory screens can now have up to 128 backgrounds.
Unit sprites recolors can now support up to 128 values.
Option for custom change of TU, HP, Energy, Morale or Stun after next turn based on unit stats.
New stat bonus based on stun level of unit.
Option for changing fuse type in granades and flare.
Option for pre-priming granades on map spawn.
Option for dodge chance based on direction of attack.
Oprion for bonus morale recovery when using medkit.
Option for self heal using medikit.

2.1:
Craft can now have up to 4 different wepon type per slot.
Oprion for overriding shape of alien base.
Option for setting chance of special effect of item.
Moving can trigger all close proxy not only one.
Corpse explosion now can have bonus based on unit stats.
Grenades now can explode at once without destroying each others.

2.2:
Option for custom sound and animation for miss attack and psi weapons.

2.3:
Option for defining percent of all action cost stats. Old use of `flatPrime` and `flatThrow` is deprecated.
Facilities can now require items to build.
Medikit can now be used without UI and can use `hitSound`.

2.4:
Option for defining bonus and damage type for melee in range weapons.
Option for big explosion sound for each items.
Option for showing fixed weapons on unit.

2.5:
Update to nightly and bug fix.

2.9:
Scripting support in unit graphic (more info in game log with debug on).
`bigSpriteAlt` and `floorSpriteAlt` is now obsolete, will be replaced by scripts in next version.
New property `refNode` used to shared values between items/solders/armors etc.
Option for setting numbers of melee hits done by AI.
Control space usage of soldiers with 2x2 armors in crafts.

3.0:
Backported game machanic changes from Meridian OXCE+.
Fix stun damage calculation and add random for random option for final stats change by damage.
Refactored script handling.
Script support in reaction atack chance calculations.
Some light handling improvments.
New recolr and replace script graphic option for items.
Option for global events shared by scripts.
Custom tags that have user defined values.

3.1:
Base building can now prevent building other buildings.
New tag type that store other mod id.
Option for changing defualt unit light radius.
New functions exposed to script.
Reaction scripts have now information about runing or strafing of target.

3.2:
New functions exposed to script.

3.3:
New light system.
Option for reserving more space for mod in common surface/sound sets.
Visibility scripts that determine visibility of targets.

3.5:
Update to buildin script functions.
Update to recent nightly OpenXcom.

3.6:
Config for new lighting system.
New map script options made by ohartenstein23.
New scripts for items and units.
Add option for grenades to explode in hand.
Changes in handlig items with prime.
Primed granades are not recoverable if consumable property is set.

3.6a:
Fix couple of bugs.
Add some missed scripts.
Add damage type param to unit damage script.

3.6b:
Fix critical bug in unit damage function.

3.7:
New params with shooting weapon and shooter to damage and hit script.
Merge chagnes from master.
Random functions in script.
Vertical map generation support.

3.8:
Add multi ammo weapons.
New param with battle action for unit hit and damage script.

3.8a:
Bug fix.

3.9:
Bug fix.
Improvments in displaying multiple ammo items in inventory.
Script altering experience grain.

3.9a:
Bug fix.

3.9b:
Bug fix.

3.9c:
Bug fix.

3.10:
Bug fix.
Update nightly.
New grenade fuse config.

3.10a:
Bug fix.
Update nightly.

3.10b:

4.0:
Damage script can now alter zombie transformation chance.
Add access to current difficulty level in scripts.
Add base function requirmets to buy items, crafts and solders.
Add access to geoscape soldier in scripts.
Add script that is run at end of mission.
Add arcing shoots per attack type (by ohartenstein23).
Breaking change: Renamed `action` to `battle_action` in reaction scripts.
Add battle action to `awardExperience` script.
Breaking change: Renamed access function to statis in armor (added prefix `Stats.`).

4.0a:
Bug fix.




Links

Current working branch:
https://github.com/Yankes/OpenXcom/tree/OpenXcomExtended

Download available on mod site (require latest nightly):
http://www.openxcom.com/mod/openxcom-extended

Backup:
https://www.mediafire.com/folder/w07p0ibc985kd/OXCE

Forum thread:
http://openxcom.org/forum/index.php?topic=2915.msg31641#msg31641



Credits

Meridian for OXCE+ :)
stiansel for FOV speedup.
redv & WarBoy1982 for a couple of commits.
SolarusScorch for fixing language in readme.
SupSuper & WarBoy1982 & Daiky for OpenXcom :)
Title: Re: OpenXcom Extended
Post by: redv on September 07, 2014, 08:25:39 pm
Do you interested in ready to use features for modders?
I.e:

* Radars of aircrafts can have not 100% chance to detect UFOs. https://github.com/SupSuper/OpenXcom/pull/932

* Hyperwave decoder used the rule "radarChance" too. https://github.com/SupSuper/OpenXcom/pull/931

* User can change rules of max view distance, max view distance at dark, max darkness to see unit. https://github.com/SupSuper/OpenXcom/pull/904
  Max view distance at dark depend of armour that you wear.

* Ammunition for HWPs used the same rules as for aircrafts. https://github.com/SupSuper/OpenXcom/pull/895
Title: Re: OpenXcom Extended
Post by: Yankes on September 07, 2014, 09:07:08 pm
Yes, when I get some free time, I will look closer on your features.
Title: Re: OpenXcom Extended
Post by: Dioxine on September 07, 2014, 09:21: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)...

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...
Title: Re: OpenXcom Extended
Post by: Solarius Scorch on September 08, 2014, 01:18:53 am
This is an immensely interesting project, and as a modder I am very excited about it, but my concern is that it might too early go a different way than the basic openxcom. In other words, it's an Openxcom 2.0 that might be lacking functionalities that will show up in the future nightlies.

Therefore I think it's essential to incorporate all openxcom nightlies to this, ASAP. Otherwise we'll have competing codes, and that would be counter-productive and perhaps even destructive to the community.

I think it would be best if features implemented here would later be merged with the basic openxcom, as a "2.0". But that depends on the devs.
Title: Re: OpenXcom Extended
Post by: Yankes on September 08, 2014, 01:37:09 am
I will try keep backward compatibility with basic OXC. Best would be if any mod could work with my version without any big rewrites.
Title: Re: OpenXcom Extended
Post by: luke83 on September 08, 2014, 01:59:34 pm
How much more freedom for Modders... THis much https://openxcom.org/forum/index.php?topic=2743.0  :P
Title: Re: OpenXcom Extended
Post by: Dave84 on September 08, 2014, 04:01:43 pm
As a lurker I had to make an account to say how exciting this idea is. I've downloaded many of the mods here and made some changes of my own, the ability to have custom damage types would open up the possibility to make much more interesting weapons. I've already looked at how the ruleset would work and thought of some changes I would make by giving different weapons custom damage types:

Grenades would do less damage to terrain, they're meant to damage living things rather than walls (applies to alien grenades specifically)
The opposite could apply to high explosive.
Stun weapons should do a small amount of health damage, and possibly cause fatal wounds.
Some new weapons could do 50/50 stun and health damage, and/or cause a larger hit to morale.
(some) armour piercing weapons could be made to be actually armour piercing.
Perhaps plasma weapons could do a large amount of damage to armour and lower morale but not so much to health, there would be more chance to survive a shot but be significantly wounded and more vulnerable afterwards.

The possibilities are nearly endless, can't wait for the exe!
Title: Re: OpenXcom Extended
Post by: Solarius Scorch on September 08, 2014, 07:37:50 pm
Greetings, Dave. (https://www.veryicon.com/icon/png/System/World%20of%20Aqua%203/HAL%209000.png)

(Sorry, couldn't resist. :P)

Grenades would do less damage to terrain, they're meant to damage living things rather than walls (applies to alien grenades specifically)

This could technically be achieved by cutting the explosion power by half and then increasing vulnerability of all units in the game by 100%, but that's a very dirty solution and would create problems with blast radius. It could be done with a special flag:
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).
Title: Re: OpenXcom Extended
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)...

https://openxcom.org/forum/index.php?topic=2788.0 - hope this isn't too convoluted, but I've come up with system that'd allow to create all sorts of "shield" items with only a short ruleset list of features and no new in-battle properties of items. Maybe you can salvage something out of it.

Another major thing would be allowing 4 weapons per craft, adding a (type) property to weapons and array of allowed types to slots, and allowing these weapons to modify the existing stats of the craft.

I just hope you won't get buried under a mountain of requests that are inevitable to follow and keep it simple, since it could mean a start of something really big...
I think about shields but I don't have jet elegant solution for that. 4 weapon is in TODO list (basic functionality is done but not merged jet).


How much more freedom for Modders... THis much https://openxcom.org/forum/index.php?topic=2743.0  :P
Tracking temporary buffs require special system for handling it. OXC don't have any thing like that. Right now I stick to ready or easy implementable features, because of this buffs are outside current scope.

As a lurker I had to make an account to say how exciting this idea is. I've downloaded many of the mods here and made some changes of my own, the ability to have custom damage types would open up the possibility to make much more interesting weapons. I've already looked at how the ruleset would work and thought of some changes I would make by giving different weapons custom damage types:

Grenades would do less damage to terrain, they're meant to damage living things rather than walls (applies to alien grenades specifically)
The opposite could apply to high explosive.
Stun weapons should do a small amount of health damage, and possibly cause fatal wounds.
Some new weapons could do 50/50 stun and health damage, and/or cause a larger hit to morale.
(some) armour piercing weapons could be made to be actually armour piercing.
Perhaps plasma weapons could do a large amount of damage to armour and lower morale but not so much to health, there would be more chance to survive a shot but be significantly wounded and more vulnerable afterwards.

The possibilities are nearly endless, can't wait for the exe!
Most of things form your list is working, only direct morale change is unimplemented.
Title: Re: OpenXcom Extended
Post by: Dave84 on September 08, 2014, 11:00:45 pm
Hi Yankes and Solarius

I should have explained better, my wish list was what I thought could be modifiable using the Unified Damage Types from here https://github.com/SupSuper/OpenXcom/pull/938 (https://github.com/SupSuper/OpenXcom/pull/938), which I assumed was was included in this mod. Like I say I've been lurking for a while, I read the link before and thought it looked cool but I'm not able to compile the code so was hoping it would be included in the nighties or released as an exe at some point.

As for changing plasma weapons, my thinking was it could work a bit like halo, where plasma weapons are quite good at destroying armor but not really much better than human weapons other than that. It could make things more interesting, although I admit it would make the game easier if plasma weapons weren't as good. But I get bored of everything being one-shot kills, so some way to make a weapon more likely to cause severe damage but not kill outright in one shot appeals to me.
Title: Re: OpenXcom Extended
Post by: Dioxine on September 09, 2014, 02:29:11 am
You can make it work with the current ruleset options, simply adding resistance to plasma to all unarmored/lightly armored targets, whatever sense does it make :)
Title: Re: OpenXcom Extended
Post by: NeoWorm on September 09, 2014, 10:05:38 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.
Title: Re: OpenXcom Extended
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.




Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
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

Title: Re: OpenXcom Extended
Post by: Dioxine on September 09, 2014, 02:34:59 pm
I think if we stick to features that aren't conflicting/redundant with what Sup & Warboy are doing, and keep features reasonable (compatible with XCom core elements & interface limitations), this is going to be merged eventually. But I wouldn't worry too much - Yankes seems to be doing this in a modular fashion so nothing that he changes is set in stone. I agree though that 1.0 is far too early to branch off - just look at all the cool features that were added to OXCom since this thread started.
Title: Re: OpenXcom Extended
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 :)
Title: Re: OpenXcom Extended
Post by: Dioxine on September 10, 2014, 11:44:16 pm
Gratz!

An extended feature idea: we have strengthApplied and psiStrengthApplied... how about adding throwingApplied? This skill sees little use as of now, it could be linked with weapons like thrown knives as a damage buff. Also, would it be possible that all these applied flags would be percentage (multiplier) instead of boolean? Adding 100% strength to weapons damage is usually an overkill...

Man, more of this and we'll have XCom: Role Playing game :)
Title: Re: OpenXcom Extended
Post by: Falko on September 10, 2014, 11:57:40 pm
good idea dioxine :)
next step 20% of intelligence applied to weapon accuracy, 30% of melee skill applied to weapon power and -25% of strength applied to tu costs .. *dream*
Title: Re: OpenXcom Extended
Post by: Yankes on September 11, 2014, 12:44:10 am
Gratz!

An extended feature idea: we have strengthApplied and psiStrengthApplied... how about adding throwingApplied? This skill sees little use as of now, it could be linked with weapons like thrown knives as a damage buff. Also, would it be possible that all these applied flags would be percentage (multiplier) instead of boolean? Adding 100% strength to weapons damage is usually an overkill...

Man, more of this and we'll have XCom: Role Playing game :)
I never intended use bool for that, only "strengthApplied" is bool for backward compatibility and new functionality use [0.0, 1.0] scale.
Current options:
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.
Title: Re: OpenXcom Extended
Post by: Ran on September 11, 2014, 01:06:54 am
Great idea, thank you for giving us new opportunities. :)
I'd love to see more functions un-hardcoded so they could be customized.

I only have 2 small requests which I think are reasonable.:

1) Enable to use medipack on yourself (would allow special food / drugs / potions without the need of having somebody else feed them to you).

2) Enable custom explosion sprites in the same way as hit sprites
Title: Re: OpenXcom Extended
Post by: RSSwizard on September 11, 2014, 01:30:10 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).
Title: Re: OpenXcom Extended
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...?
Title: Re: OpenXcom Extended
Post by: arrakis69ct on September 11, 2014, 02:37:26 pm
Taking site

Enviado desde mi LG-D802 mediante Tapatalk

Title: Re: OpenXcom Extended
Post by: Dioxine on September 11, 2014, 04:24:43 pm
Good idea with including the overall Psi in this damage formula... A modder has to be careful with that though as it maxes out at 10k (even 10200 I think) :) I love when soldier's stats are relevant to tactics in many aspects.

@Ran: I support this on both accounts although I think Warboy will (fingers crossed) create custom explosion sprites support as a part of TFTD (it needs separate underwater & above-water explosions).
Title: Re: OpenXcom Extended
Post by: Dave84 on September 11, 2014, 10:10:39 pm
Not sure if it's just me, but I can't get the exe to work. It loads up ok, but crashes when I try and start a new game or battle.
Title: Re: OpenXcom Extended
Post by: Yankes on September 11, 2014, 10:21:24 pm
What version of OpenXcom did you have? And what error you get?
I build it based on recent nightly. Additional I tried recreate toolchain that is used for nightly builds.
Every thing should work similar way to original version of OXC.
Title: Re: OpenXcom Extended
Post by: Dave84 on September 11, 2014, 10:26:11 pm
I have version 1.0, I'll downloading the latest nightly first and try again.
Title: Re: OpenXcom Extended
Post by: Dave84 on September 11, 2014, 11:17:35 pm
Yeah that was my problem, it's working now.

Do you have any example rulesets you could share? How would I go about making stun damage also do some health damage? Is it possible to add a new damage type, if so how would I do that and get a weapon to use it?
Title: Re: OpenXcom Extended
Post by: Yankes on September 12, 2014, 12:29:15 am
I have snippets for item (like stun rod):
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.
Title: Re: OpenXcom Extended
Post by: Voiddweller on September 13, 2014, 12:29:17 am
Awesome idea, but where i can find a new options list?
Edit: It seems to have a habit to crash after i end tactical mission either by escaping or completing it. Non-mod related bug. Latest version used.
Title: Re: OpenXcom Extended
Post by: redv on September 13, 2014, 10:57:08 am
Latest build contain ViewDistance mod. https://www.openxcom.com/mod/openxcom-extended
You can change maximum view distance, view distance at dark, threshold between daytime and night vision rules.

This ruleset contain rules by default (see attachment). It is a good starting point for your own rules.

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
Title: Re: OpenXcom Extended
Post by: Dave84 on September 13, 2014, 11:54:18 am
I've attached my ruleset so far, I've made the stun rod and stun bomb do health damage and cause wounds, and incendiary clips and rockets do real upfront damage. Tested both in a battle and they seem to work as expected.

I got the crashing issue with the new exe too, after leaving a battle. I've moved back to the previous exe for now, which doesn't seem to have the same issue.
Title: Re: OpenXcom Extended
Post by: Solarius Scorch on September 13, 2014, 12:44:30 pm
I have a personal request:

I would really like to be sable to disable a certain mission up to a certain point of time, for example "don't create terror missions before August 1999" (just an example, not a part of an actual project). The easiest way to do this would be to enable it in alienMissions, as an additional flag somehow.
Title: Re: OpenXcom Extended
Post by: Yankes on September 13, 2014, 01:32:39 pm
Latest build contain ViewDistance mod. https://www.openxcom.com/mod/openxcom-extended
You can change maximum view distance, view distance at dark, threshold between daytime and night vision rules.

This ruleset contain rules by default (see attachment). It is a good starting point for your own rules.

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 altered redv mod that you don't need define default "9" range for solders.

I've attached my ruleset so far, I've made the stun rod and stun bomb do health damage and cause wounds, and incendiary clips and rockets do real upfront damage. Tested both in a battle and they seem to work as expected.

I got the crashing issue with the new exe too, after leaving a battle. I've moved back to the previous exe for now, which doesn't seem to have the same issue.
Every mission, or only one? I would be glad if you send me save from that mission. Meanwhile I will try reproduce it myself.
Title: Re: OpenXcom Extended
Post by: Voiddweller on September 13, 2014, 03:15:47 pm
New version crash on start for me :P
Title: Re: OpenXcom Extended
Post by: Yankes on September 13, 2014, 06:03:55 pm
Do you used 1.0 or Nightly? if 1.0 then its to old. My version require Nightly to work.

Because of some strange error in my toolchain I get crash at end of every mission, if I sue different compiler, everything works fine.
I will try find cause of this.

--- posts merge ---

Ok, I find culprit, again its Warboy fault :D.
I include recent changes form Nightly, and Warboy add new functionality and changed default ruleset.
New nightly is required as base for exe.
Title: Re: OpenXcom Extended
Post by: ivandogovich on September 13, 2014, 06:59:52 pm
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.


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
Title: Re: OpenXcom Extended
Post by: NeoWorm on September 13, 2014, 07:31:27 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.

Otherwise, the increased nightvision for X-Com soldiers seems to work fine.
Title: Re: OpenXcom Extended
Post by: Yankes on September 13, 2014, 07:49:56 pm
I updated a bit first post. More info about changes in extended version.

I've been toying with the night visibility options and I want to ask one thing - The light emmited from X-Com Soldiers is counted as normal light by the engine? Because if so, Aliens will never use their nightvision stat, because every X-com soldier is standing in the light.

Otherwise, the increased nightvision for X-Com soldiers seems to work fine.
I don't know, redv add this feature and he probably know answer for that.
Title: Re: OpenXcom Extended
Post by: NeoWorm on September 13, 2014, 08:10:46 pm
How hard would it be to add option to disable soldier glow depending on armor used? Or maybe even add option to have enemies that glow. I tried to find where the glow is applied in the battlescape engine but its beyond my skills (it took me 5 hours and 4 tries to get the git and visual studio working).
Title: Re: OpenXcom Extended
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".
Title: Re: OpenXcom Extended
Post by: NeoWorm on September 13, 2014, 09:20:11 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.

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.

Title: Re: OpenXcom Extended
Post by: NeoWorm on September 14, 2014, 01:49:50 am
Well, I somehow managed to externalize unit glows and it seems to work. My code is probably terrible and should be rewritten but  it is good enough for a proof that it's possible and as toy for me to find out how useful it can be. At least hunting glowing blind mutons in darkness is fun.

When I figure out how to post the code to git I will send link there.
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: redv on September 14, 2014, 05:19:06 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.
Title: Re: OpenXcom Extended
Post by: Falko on September 14, 2014, 05:41:03 pm
doing it differently would be strange
xcom is a turnbased game!
if i play oxc/monopoly/chess and close my eyes during my turn the opponents pieces dont move because i cant see them with eyes closed
sure in oxc they can shoot back but that does not change the principle of "i know there is an alien" even if the spotter is killed
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: redv on September 15, 2014, 11:17:15 am
About use case of radarChance of Hyperwave decoder.
Default value is 100. For instance, if set:
Code: [Select]
facilities:
  - type: STR_HYPER_WAVE_DECODER
    radarChance: 50
then chance of detection of UFOs will be 50/50 every 30 min.


Interesting option will be if set radarChance to 0.
Code: [Select]
facilities:
  - type: STR_HYPER_WAVE_DECODER
    radarChance: 0
In this case hyperwave decoder cannot determine position of UFO but can decode an UFOs transmissions.

My scenario:
1. Conventional radars detects UFOs.
2. Then, after 30 min, hyperwave decoder decodes transmissions and gives additional information about UFO. Blue info screen changes to red.

Looks realistic:)
Title: Re: OpenXcom Extended
Post by: Solarius Scorch on September 15, 2014, 07:42:30 pm
Interesting option will be if set radarChance to 0.
Code: [Select]
facilities:
  - type: STR_HYPER_WAVE_DECODER
    radarChance: 0
In this case hyperwave decoder cannot determine position of UFO but can decode an UFOs transmissions.

Sorry, please clarify if this is true for the OpenXCom Extended only, or works for vanilla OpenXCom as well?
Title: Re: OpenXcom Extended
Post by: Yankes on September 15, 2014, 08:59:29 pm
Extended, vanilla have always 100%
Title: Re: OpenXcom Extended
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
Title: Re: OpenXcom Extended
Post by: pkrcel on September 15, 2014, 09:14:13 pm
It makes a lot of sense, thou 30 minutes might be both A LOT or NO SWEAT.

I'll try out it in the future
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: Yankes on September 16, 2014, 12:51:38 am
Next build of OpenXcomExtended will have some craft improvements.
Now every craft can have up to 4 weapons.
Every weapon slot and every weapon can have defined weapon type.
Only weapons with same type can be equipped in that weapon slot.

craft:
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.


Title: Re: OpenXcom Extended
Post by: Vulgar Monkey on September 16, 2014, 01:50:58 am
Yep. I read a thing a while ago too (possibly the same thing) saying that the military is starting to lean away from using buildings as cover from small arms due to thermobaric warheads becoming more prolific on the arms market.

They did a study iirc and found that, all things being equal, they'd usually just be better off being shot at individually than putting all their eggs in one basket, so to speak.

Also, for some reason (probably something to do with transmission of the concussive blast) ordinary ballistic armour actually makes such threats MORE dangerous. So ingame that'd be a negative damage modifier I guess, although having armour that makes your more vulnerable to explosives does seem very counterintuitive.
Title: Re: OpenXcom Extended
Post by: arrakis69ct on September 16, 2014, 12:21:12 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

Enviado desde mi LG-D802 mediante Tapatalk
Title: Re: OpenXcom Extended
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!)
Title: Re: OpenXcom Extended
Post by: Dioxine on September 16, 2014, 01:27:20 pm
Maybe with colored bars? Every stat has a different color, so soldier name followed by multi-colored bar - each +1 is 2 pixels width of a given color...

I agree with you on principle (it is sudoku-difficult as the soldiers increase a lot of stats) but seeing stat increases would be awesome none the less :)
Title: Re: OpenXcom Extended
Post by: pkrcel on September 16, 2014, 02:33:09 pm
It's a neat idea, and besides I don't see the problem of the UI.

Of course one woudl have to design a new debrief screen with the soldiers stats embedded.....

Title: Re: OpenXcom Extended
Post by: Dave84 on September 16, 2014, 03:43:12 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?

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.
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: KingMob4313 on September 16, 2014, 10:03:48 pm
Can I pull down a branch and work on fixing the shotgun hack so that is not a hack?
Title: Re: OpenXcom Extended
Post by: Yankes on September 16, 2014, 10:41:12 pm
Yup, if result is less hackly than current solution I will gladly include it to may branch.
BTW do you have plan how to fix it?
Title: Re: OpenXcom Extended
Post by: Yankes on September 18, 2014, 11:37:31 pm
New feature, crafts weapon can alter craft stats.
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
Title: Re: OpenXcom Extended
Post by: arrakis69ct on September 19, 2014, 02:31:33 am
Ohhhh posibilities. Fuel extend .  turbo boost. Power acelerator.

May be extra cargo for skiranger??? More soldiers or one more tank XD

Enviado desde mi LG-D802 mediante Tapatalk
Title: Re: OpenXcom Extended
Post by: robin on September 19, 2014, 11:05:04 am
New feature, crafts weapon can alter craft stats.
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
this + the 4 slots.. if the goal was an Apocalypse-like customization (for crafts), then you have reached it.

(Now we'd need UFOs to do a little more too, they should at least have the option to get a second weapon :P ).

I haven't followed the development, but I wish this to be integrated with the main OXC release.
Title: Re: OpenXcom Extended
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!
Title: Re: OpenXcom Extended
Post by: Yankes on September 19, 2014, 07:01:16 pm
May be extra cargo for skiranger??? More soldiers or one more tank XD
This will require to much effort to implement that this is worth. This is limited primary by battlescape and adding any number will not fix that.
Another problem is adding new code that will throwing out stuff from craft when you remove weapon that give out additional solder/tank slot.
Title: Re: OpenXcom Extended
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.
Another problem is adding new code that will throwing out stuff from craft when you remove weapon that give out additional solder/tank slot.
Ok. Only is a idea. But may be possible others options in future.

Enviado desde mi LG-D802 mediante Tapatalk

Title: Re: OpenXcom Extended
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. :)
Title: Re: OpenXcom Extended
Post by: Dioxine on September 20, 2014, 10:56:54 am
Yeah it'd be best for the AI formula to simulate player's line of thought, meaning it'd usually go for a maximum overall chance to hit (hence range calculations are crucial), with a random factor added.
Title: Re: OpenXcom Extended
Post by: Yankes on September 22, 2014, 08:24:00 pm
Small update with two changes:
`fix fixed weapon (should always placed into "hands")` by redv
`Support for fire and smoke for any damage type`

And recent fix form nightly.
Title: Re: OpenXcom Extended
Post by: Yankes on September 28, 2014, 03:03:28 am
new build,

I added bit more depth to craft combat. Now craft & ufo can have armor that reduce damage, better hit chance and better avoidance.
New hit formula:
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+).

Title: Re: OpenXcom Extended
Post by: Solarius Scorch on September 28, 2014, 08:30:50 am
Awesome. I'm obviously happy for my request being granted, and the new air combat mechanics are very exciting.
Title: Re: OpenXcom Extended
Post by: Dioxine on September 28, 2014, 09:38:06 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)?
Title: Re: OpenXcom Extended
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".
Title: Re: OpenXcom Extended
Post by: Dioxine on September 28, 2014, 11:47:04 am
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.
Title: Re: OpenXcom Extended
Post by: redv on September 28, 2014, 12:26:00 pm
"Dropoff" of firearms (different by type of shots) is just a silly workaround instead of using true "range based accuracy" formula.
Artificial "dropoff" of psi abilities will be the same workaround. You can balance psi-interactions by increasing psi-strength of aliens (for instance +30 or +40 psi str works well).
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: redv on September 28, 2014, 03:00:20 pm
"Dropoff" introduced in UFO Extender. I mean UFO Extender Accuracy is a silly workaround. For instance, you see that your chance to hit 50%. In attached picture you can see a difference among different models of shooting. So, UFO Extender accuracy looks very strange.
Title: Re: OpenXcom Extended
Post by: Arthanor on September 28, 2014, 07:45:54 pm
Shouldn't your graph look more like " -< " for the UFOExtender Accuracy? There is no big loss in accuracy at a certain point (your horizontals), just that you start losing some in a linear fashion after a certain distance.

If you want weapons that behave like your graph on the left, just give them high accuracy and an optimal range of 1, then the dropoff will kick in and reduce your accuracy linearly with distance starting 2 tiles away. The system is there.

I agree with Dioxine that adding a "DistanceFactor" that can be modded would be a good thing for mods. Changing the equation to:

Attack Success (A%) = 100/56 * ( Constant + AS - DS - DistanceFactor*Distance )

would allow to give more or less impact to distance depending on what the modder intends, which is not the same as just a flat increase in alien psi strength.

With that, you could make the psi system more complex, with XCom's first psiamp having a huge distance factor so it is really short range, then later version diminishing that to represent better understanding of psi-tech. Or.. I'm not sure if it is possible to give different psi-weapons to the aliens, but sectoids could have a larger factor, representing that they are not as adept mind controllers as Ethereals (who themselves could have various versions by ranks, some which need LoS, some which don't).

There's a lot that could be done with the psi-system. Externalizing the parameters would be great.
Title: Re: OpenXcom Extended
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?
Title: Re: OpenXcom Extended
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)
Title: Re: OpenXcom Extended
Post by: Arthanor on September 28, 2014, 08:30:35 pm
It's wrong.
Angle in range based accuracy depends on accuracy. But angle in UFO extender will be always the same (~pi/2) even if you set 100% accuracy.
That's true, the accuracy loss is always the same for a given weapon, range & shot combination. It might be better if it depended on the soldier as well. But given that the initial accuracy does depend on the soldier, the accuracy at range does too. A better marksman will have better odds of hitting at long range, just by virtue of having a greater chance to hit from which to substract the range adjustment.

You can control the angle by setting the "dropoff" properties of weapons, the increment by which accuracy is reduced for a tile (default = 2, but you can set a shotgun to, say, 5 so it becomes useless quickly at range, and a marksman or laser rifle to 1, to represent that range has little impact).

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..! ;)
Title: Re: OpenXcom Extended
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
Title: Re: OpenXcom Extended
Post by: Arthanor on September 28, 2014, 09:17:50 pm
I'm starting to think we're talking about different things.

From the code, it does seem like the dropoff is taken into account, so your accuracy (the % to hit displayed on top of your cursor) depends on: Firing accuracy, weapon accuracy and the distance beyond max range * dropoff. Basically, chance to hit = FiringAccuracy * WeaponAccuracy - (DistanceOverMax * DropOff).

Now if that value drops to zero or lower, it is set to 0. Afterall, you can't have less than a 0% chance to hit. What happens when it is 0% is beyond me from a code perspective, but game wise, you miss, which is as expected.

I was talking about the period during which accuracy is above 0% and how that value decreases. I am guessing you are talking of when it hits 0% and beyond? And/Or about what happens when you have above 0% but miss the shot? In those cases, where the shot goes can indeed be really weird (and usually tends to be towards a fellow operative, or a civilian ;)). That could (should?) indeed be improved upon so I guess.. we agree on that?
Title: Re: OpenXcom Extended
Post by: Dioxine on September 28, 2014, 09:22:46 pm
@redv
Let's take 2 instances of MC attempt. In the first one, I am increasing alien's Psi strength by +10. In the other, I am increasing Distance factor by a factor of 2.

Each of these 2 instances will be cacled for ranges 10, 20 and 30. Let's assume Psi Str attacker = 100, Skill = 50 and basic Psi Str of an alien = 30

So, AS is constant (5000/50 = 100) while DS is 30 in the first case, 40 in the second case.


1.
A%@dist 10 = 0.56*(25+100-40-10) = 0.56*75 = 42
A%@dist 20 = 0.56*(25+100-40-20) = 0.56*65 = 36.4
A%@dist 30 = 0.56*(25+100-40-30) = 0.56*55 = 30.8

2.
A%@dist 10 = 0.56*(25+100-30-20) = 0.56*75 = 42
A%@dist 20 = 0.56*(25+100-30-40) = 0.56*55 = 30.8
A%@dist 30 = 0.56*(25+100-30-60) = 0.56*35 = 19.6

As you can see, while it is possible to balance with enemy's Psi Str on a given distance, the results are quite different for different distances. And I don't quite get what "artificial solution" means and what does it all have to do with projectile cones and angles.

EDIT: but I think you're saying that instead of an artificial % chance, the effective accuracy@range should effect the deviation of a bullet, thus rendering UFO's current accuracy formulas useless.

EDIT2: to be more clear, the current accuracy operator is "a chance to pick the perfect trajectory"; in your approach, this would be irrelevant, as accuracy operator would be "the tighteness of Gaussian cone of possible deviation angles". Am I right?
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: Dioxine on September 29, 2014, 02:04:08 am
50% hit chance in vanilla means there's a 50% chance of "autoaim" kicking in and the bullet following a trajectry that the game calculates as a true shot; and 50% of it going randomly astray.

Let's start calling your system "angle-based accuracy" because the XComUtil system is also based on range (as opposed to binary accuracy in vanilla), so your monicker "range-based accuracy" is either sloppy or consciously misleading.

However I am not sure if it will work. For starters, we assume the formula is not cheating and calculates deviation without any secret modifiers. Therefore the hit chances drop geometrically: if at 10 tiles away a target has a cross-section, for example, 20 units, it will only have a cross-section of 5 at 40 tiles away. A 100% hit chance at 10 tiles turns into 50% chance at 20 tiles, 25% hit chance at 40 tiles and so on. While this would work for a game with real ranges involved, I am not 100% sure it will work for much more abstract XCom.

Perhaps more sensible will be adding a better Gaussian formula to the current system, which would kick in when the shot misses; so it doesn't miss randomly but in a flexible cone dependant on the original to-hit chances. However if the cone is too tight, much of the dice-rolled misses would hit anyway, so it wouldn't be any good.
Title: Re: OpenXcom Extended
Post by: Falko on September 29, 2014, 02:13:33 am
i made an image that shows the drop of accuracy using pure "angle" based accuracy
i defined 100% accuracy as always hits ethereal sized unit from 6 tiles away (if no obstacle)
one can of course change the distance (6) part but the geometrical loss of accuracy always leads to "use the best accuracy weapon"-strategy in all cases :/
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: Arthanor on September 29, 2014, 02:30:33 am
Nice work Falko!

One thing we see is that accuracy drops faster and faster as distance increase (fixed cross-section compared to the sherical area which grows as r^2) and means you better be standing right in the face of something to hit it. This explains why it's so hard to hit things in real life (a small deviation in aim means you're missing by a huge amount with some distance), but wouldn't be much fun in XCom, except maybe for a Really Up Close and Personal where you mostly use melee and don't bother shooting outside of a few tiles.

Perhaps more sensible will be adding a better Gaussian formula to the current system, which would kick in when the shot misses; so it doesn't miss randomly but in a flexible cone dependant on the original to-hit chances. However if the cone is too tight, much of the dice-rolled misses would hit anyway, so it wouldn't be any good.

YES! Please! Get rid of "sniper hits 95% of the time, but boy, when he misses, the shot actually goes sideways!". And maybe tighten the gaussian depending on the shot type? From autoshot being pretty wide to aimed shot being pretty tight?
Title: Re: OpenXcom Extended
Post by: Dioxine on September 29, 2014, 03:39:45 am
A gaussian dice roll, and a formula that only improves upon the current model, instead of throwing it out of the window. The % value calced by Xcomutil Extender still holds true... *in lab environment*. For a standard-sized target. Suddenly though, 100% shots start to miss when there is some cover involved, or the target is small. Conversely, a dice roll that would normally be a few points short of the target value and go completely astray (like that 95% sniper) could still reliably hit a HWP or even a big powered armor with a large Loftemps cross-section defined (you may not know that, but 1-tile units have 5 or 6 varied thickness cyllinders to represent them in 3d space). Accuracy values of over 100% would finally be of use to defeat cover; and most importantly for myself, kneeling behind a rock or shooting from a window would make you really less likely to be hit.

(https://i242.photobucket.com/albums/ff62/max_smirnov/Hits_zps093e4665.png) (https://s242.photobucket.com/user/max_smirnov/media/Hits_zps093e4665.png.html)

(https://i242.photobucket.com/albums/ff62/max_smirnov/DiceBasedDeviations_zpsaa6b6c5b.png) (https://s242.photobucket.com/user/max_smirnov/media/DiceBasedDeviations_zpsaa6b6c5b.png.html)

Title: Re: OpenXcom Extended
Post by: Falko on September 29, 2014, 03:50:51 am
a solution to counteract the geometrical loss of accuracy:
instead of randomly shooting within the cone of fire we would shoot more frequently in the middle and less frequently on the edges of the cone
see image
lets say " [snap,auto,aim]Range" defines the distance where shot on ethereal sized unit hits 50% of the time (without obstacles) so " [snap,auto,aim]Range" defines the maximal size of the cone(angle)
and accuracy defines the angle distribution so high accuracy soldier + high accuracy weapon = very high likelihood to hit exactly in center and hopefully avoid obstacles or hit targets further away
it makes hitting 4tile units easier then now
i think it makes  close combat more realistic
it makes use out of accuracy values >100%
[not sure how exactly shotguns work so no idea how it would integrate into this]

enabling angle based accuracy would need to lower the aimrange default value to ~40 so we can calculate a realistic sized cone for each shot type that does not overpower the aimshot

Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: Dioxine on September 29, 2014, 05:00:05 am
Then I clearly misunderstood you, sorry. I was thinking of replacing the base mechanics that selects a "golden" trajectory with a cone of fire (hence angle), with a gaussian spread. Could you explain how your system works, in math terms, because not everyone knows C++? Doesn't it make current weapon stats completely off-balanced?

(about the scripts that mod the hit chance based on disputable ideas like not seen personally or recoil - this is beside the point now)
Title: Re: OpenXcom Extended
Post by: redv on September 29, 2014, 05:13:42 am
1. calculate a baseDeviation in radian (+- 3 sigma) https://github.com/redv/OpenXcom/blob/rigth_shot_chance_view/src/Battlescape/Projectile.cpp#L352
 restrictions: 0.02 <= baseDeviation <= 2.45

2. calculate horizontal and vertical deviations in radian, based on normal distribution (you calls it "gaussian spread")
https://github.com/redv/OpenXcom/blob/rigth_shot_chance_view/src/Battlescape/Projectile.cpp#L363

3. calculate a target voxel: https://github.com/redv/OpenXcom/blob/rigth_shot_chance_view/src/Battlescape/Projectile.cpp#L372

it's all:)
Title: Re: OpenXcom Extended
Post by: Dioxine on October 01, 2014, 09:19:00 pm
@Yankes! I just remembered an important feature that's missing in the original: ability to declare (if desired) separate bigob and floorob for a creature/soldier that's not killed only stunned. Could it be added to the wishlist at least? :)
Title: Re: OpenXcom Extended
Post by: Yankes on October 01, 2014, 10:48:52 pm
I will try do it in next build.
Title: Re: OpenXcom Extended
Post by: The Reaver of Darkness on October 02, 2014, 10:44:40 am
This is looking pretty great! Keep up the good work!
Title: Re: OpenXcom Extended
Post by: pkrcel on October 02, 2014, 10:18:05 pm
Yankes/redv, a proposal for an extended feature that should be pullable easily into UPSTREAM: make soldiers in a base sortable even f there is no trooper craft (i.e. Radar Base defense troopers), best would be if they could also be equipped & armored like in the equip craft screen.

I know it is of limited use since there is real "deployment order" on base defense but it's a perk of mine to be able to set up my squad in advance and sort them as well.

Cheers.
Andy

 
Title: Re: OpenXcom Extended
Post by: Yankes on October 03, 2014, 07:31:16 pm
This would better fit official branch. Another things is scope of my mod, I prefer stick to ruleset improvements for mod authors. 
Title: Re: OpenXcom Extended
Post by: new_civilian on October 04, 2014, 02:21:20 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...  :-[

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*....  :)
Title: Re: OpenXcom Extended
Post by: Yankes on October 04, 2014, 07:34:49 pm
New update.

All ammo types have new property "powerRangeReduction" reducing power per tile passed.
Psi-amp now can use weapon "power" as bonus to psi attack, can use "damageBonus" and "powerRangeReduction".

Weapons, grenades and corpses have "floorSpriteAlt" and "bigSpriteAlt" for live unit, loaded gun and armed grenade.


My small PC is having performance problems with this mod (and the Real Vision exe as well), so I have to stick to the default exe...  :-[
Did you increase vision range? without it performance should be equal.
Title: Re: OpenXcom Extended
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. :)
Title: Re: OpenXcom Extended
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?
Title: Re: OpenXcom Extended
Post by: Dioxine on October 05, 2014, 02:52:53 am
You people are really, really tempting me to move my mod developement to this Extended version...  You'll be catching, if not the best, then at least the largest mod out there :)

Question: are night/day sight ranges already implemented (and hopefully armor-dependant)? I don't want anything as radical as Real Vision, but in my mod (and perhaps others) you're, for example, facing humans, who shouldn't see in the dark any better than you do... Also swicthable personal light! I can actually navigate my soldiers in complete darkness. Naturally this isn't an easy order, because without the flashlight, there should be an option to see the battlefield in some sort of NV... (a simple monochrome filter that's activated by a hotkey and shows all visible tiles as lit-up, even in complete darkness? Alternatively, every unit, enemy or otherwise could simply emit *very* weak light, like strength 10 or below, and the right visibility can be adjusted based on that premise...

Oh yeah and an enhancement suggestion: Afaik Warboy overrode Sup's suggestion that BuiltInWeapons should be tied to armors, not units. Which is a wrong move, because tying them to armors doesn't yield any special problems, BUT allows X-Com soldiers to use 2x2 armor suits! (tested, works, but ofc without the possibility to have any weapons); and I tell you, a soldier prancing around in a SECTOPOD armor feels just AWESOME. Or generally suits of armor with built-in weapons which modders would certainly appreciate... (Terminator Suits? One hand free, the other has a Power Fist :) )

And even less important suggestion. Would it be possible for an armor to have a list of *disabled* inventory sections? Ex. if a guy has a formal suit, he shouldn't be able to use backpack. :)

Oh and there is a certain... bug? Despite the hand having 2x3 size, it can hold an object of any size. Should this be disabled? What do you think? I am not sure myself, they're pros and cons here.

One more! Weapons doing direct Morale damage (with that, I could finally make a properly working incendiary), treating (110-Bravery) as Resistance. So ex. a flamethrower deals 200 Morale damage, completely panicking anyone of Bravery 60 or less, but doing only 20 morale damage to a 100 Bravery guy. Ofc this base resistance is further multiplied by standard fire res (so a Power Armored guy is completely immune, but if we dropped Reaper to 100 Bravery, with his 170% fire weakness, he'd suffer 34 morale damage, instead of 20)...
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: Yankes on October 05, 2014, 06:29:06 pm
I confirmed that toolchain I use for creating release build have some bug that causing lower performance than normal.
I'm now working on fixing it.

You people are really, really tempting me to move my mod developement to this Extended version...  You'll be catching, if not the best, then at least the largest mod out there :)

Question: are night/day sight ranges already implemented (and hopefully armor-dependant)? I don't want anything as radical as Real Vision, but in my mod (and perhaps others) you're, for example, facing humans, who shouldn't see in the dark any better than you do... Also swicthable personal light! I can actually navigate my soldiers in complete darkness. Naturally this isn't an easy order, because without the flashlight, there should be an option to see the battlefield in some sort of NV... (a simple monochrome filter that's activated by a hotkey and shows all visible tiles as lit-up, even in complete darkness? Alternatively, every unit, enemy or otherwise could simply emit *very* weak light, like strength 10 or below, and the right visibility can be adjusted based on that premise...

Oh yeah and an enhancement suggestion: Afaik Warboy overrode Sup's suggestion that BuiltInWeapons should be tied to armors, not units. Which is a wrong move, because tying them to armors doesn't yield any special problems, BUT allows X-Com soldiers to use 2x2 armor suits! (tested, works, but ofc without the possibility to have any weapons); and I tell you, a soldier prancing around in a SECTOPOD armor feels just AWESOME. Or generally suits of armor with built-in weapons which modders would certainly appreciate... (Terminator Suits? One hand free, the other has a Power Fist :) )

And even less important suggestion. Would it be possible for an armor to have a list of *disabled* inventory sections? Ex. if a guy has a formal suit, he shouldn't be able to use backpack. :)

Oh and there is a certain... bug? Despite the hand having 2x3 size, it can hold an object of any size. Should this be disabled? What do you think? I am not sure myself, they're pros and cons here.

One more! Weapons doing direct Morale damage (with that, I could finally make a properly working incendiary), treating (110-Bravery) as Resistance. So ex. a flamethrower deals 200 Morale damage, completely panicking anyone of Bravery 60 or less, but doing only 20 morale damage to a 100 Bravery guy. Ofc this base resistance is further multiplied by standard fire res (so a Power Armored guy is completely immune, but if we dropped Reaper to 100 Bravery, with his 170% fire weakness, he'd suffer 34 morale damage, instead of 20)...
This is per armor. Without value its use 20 for enemies or 9 for rest.

Fixed weapons for armor can be added. I will look on this in next week. If I don't encounter any roadblocks it will be done.

Disabling inventory parts will be more tricky because it's used in multiple places (AI, auto/pre-battle  equip, UI). Right now I say it's on TODO list.

Normal game don't have problems with this because all items have smaller or equal size. What is point in objects bigger than 2x3? Depending on this we could answer if that objects could be hold in hands.

"ToMorale" can be added easily (I will add "ToEnergy" too), but only concerns is what do with current morale loose behavior (final damage to health and wounds)? I think about options "IgnoreMoraleLose" that turn off standard behavior.
Title: Re: OpenXcom Extended
Post by: new_civilian on October 06, 2014, 11:55:49 am
Good to hear that about the rework! And please: Remember to add some documentation, pleeeeease!  ;D
Title: Re: OpenXcom Extended
Post by: Yankes on October 06, 2014, 08:57:46 pm
find 10 differences:
Code: [Select]
CXXFLAGS = -Wall -o3 -s `$(SDL_CONFIG) --cflags`and
Code: [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!  ;D
Documentation could be first post in this thread and mod page. I didn't add any documentation because I didn't except anyone for using my mode as standalone. This should be base/additional for bigger mods. In ext build I will add some readme to zip.
Title: Re: OpenXcom Extended
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...
Title: Re: OpenXcom Extended
Post by: redv on October 07, 2014, 11:21:14 am
In latest OpenXcom Extended, personal lighting not taken into account when calculating visibility. Therefore personal lighting now just for comfort but not as a part of gameplay.
Looks like it works as expected, but i need feedback.

Attached file contains ruleset:
1. maximum view distance is 22 tiles
2. enemy regular units can see at night up to 19 tiles (and up to 22 if good lighting)
3. enemy terror units can see at night up to 22 tiles

Of course, you can set your own values, but anyway i need your opinion:
How changed behavior of aliens?
Is it works as expected?
Title: Re: OpenXcom Extended
Post by: guille1434 on October 07, 2014, 07:17:54 pm
Hello! Thanks for the excellent work of giving more options to Open X-Com players and modders!

One question: Which version of the "official" Open X-Com executable is the OXC Extended .exe based on? Is it based always on the last nightly build (I see that both versions are not being updated in synchronicity)

Some requests that I would like you to consider:

1) The possibility to add Accuracy, time units and arcingShot values to ammo clips, which when loaded in the weapon, will override the same values present in the weapon ruleset... Example: To mod a rifle with an underbarrel grenade launcher, it would be good to use the TU and Acc from the weapon if using it with its regular bullet ammo magazine, but when replacing that magazine and loading a grenade(s) clip, the weapon should "use" the TU and Acc from the grenade clip ruleset (which, may be it can have less accuracy, less range, but a high angle trajectory and more HE power than the bullet magazine).

2) Add  a system of weapon types (similar to the excellent system added to craft in OpenXcom Extended) for armor suits... This way we can mod heavy infantry weapons that would be only possible to carry and fire when the soldier is using a specific armor suit type. An example: it's not possible for a regular soldier to hold and fire a minigun type machine gun, because of its eneormous recoil forces, but if the soldier is wearing a power suit, this suit can handle such a weapon.

Example: a)  Add to armors a "weapon hardpoint" stat, this would have a numerical value...

                b) This hardpoint value will be checked against a new "weapon type" stat, or even without needing to add any new stats, to the weapon weight value. If the weapon weight (or type)
                    value is lower or equal to the armor suit hardpoint value, this weapon is compatible, if the weight/type number of the weapon is higher, that weapon would not be able to be used by
                    troops wearing that armor suit.


I think such additions will give more flexibility and tactical options, and will not invalidate any current options available to the modders and gamers.

Thanks for your attention!
Title: Re: OpenXcom Extended
Post by: Yankes on October 07, 2014, 09:06:30 pm
last version is based on Nightly from 2014-10-02, I don't updated because master branch only get some code used by TFTD. Overall when I create new build I sync with master branch.

1) Possible but will require lot of boilerplate code for handling all of properties. I will think about this.
2) Right now I consider adding fixed weapons to armors, this will give most of this functionality (armors with very big guns). It will have limitations too but it will require less coding because most of functionality is already in game.
Title: Re: OpenXcom Extended
Post by: guille1434 on October 07, 2014, 10:35:00 pm
Yankes: Thanks for taking your time for reading my suggestions. Do as you see fit...

Anyway, I think that the weapon slot is a more flexible approach to the theme of "armor specific weapons"... I hope you find sometime the way to implement that... am not in a hurry... I am very grateful with what you give the community with your work!
Title: Re: OpenXcom Extended
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 ;)
Title: Re: OpenXcom Extended
Post by: guille1434 on October 08, 2014, 06:25:54 pm
Yes, but that approach leaves the way open for the player to load a lot of other different things in place of that weapon... I think that if it is no very complicated to code in, this would be a nice addition.
Title: Re: OpenXcom Extended
Post by: Dioxine on October 09, 2014, 05:05:49 am
Hmm... this idea, after some refinement could be used to implement shields and other stat-changing items that won't be removable during the mission (as the possibility to make them removeable would require a ton of extra coding and would be very bug-friendly). So perhaps this could be it, but the "hardpoint" thing would have to be thought over; ex. defining it for every armor seems suboptimal. So I agree there is space where it could be implemented for the benefit of mankind, but how exactly and when, it's up to the creators of the Extended I guess :)
Title: Re: OpenXcom Extended
Post by: Falko on October 10, 2014, 02:49:21 am
from irc:
[..] would it be hard to make a function "drop primed grenade on 'unload'-button to un-prime grenade for 50%? of primecosts" ?
[..]
<SupSuper>i dunno, technically it's easy to code, [..]
<SupSuper>maybe suggest it to openxcom extended
<FalkoO>ok
<SupSuper>at least dragging to unload is probably something you can't do accidentally
Title: Re: OpenXcom Extended
Post by: VSx86 on October 10, 2014, 04:48:17 pm
Extending the abilities for modding is always good, because you allow and provide
more options for creative work. I suspect that many of OXXT (OpenXcom eXTended)
innovations will be added to main OXC sooner or later.  ;)
Title: Re: OpenXcom Extended
Post by: Yankes on October 10, 2014, 09:18:54 pm
from irc:
[..] would it be hard to make a function "drop primed grenade on 'unload'-button to un-prime grenade for 50%? of primecosts" ?
[..]
<SupSuper>i dunno, technically it's easy to code, [..]
<SupSuper>maybe suggest it to openxcom extended
<FalkoO>ok
<SupSuper>at least dragging to unload is probably something you can't do accidentally
I will think about this. This probably will be easy to do.

Extending the abilities for modding is always good, because you allow and provide
more options for creative work. I suspect that many of OXXT (OpenXcom eXTended)
innovations will be added to main OXC sooner or later.  ;)
Probably later ;P Its because my primary goal is create mod platform not obey original rules. I already made some changes that should no be in basic OXC.
Example of this is how I handle unconscious unit under explosion, In my version explosion must kill unit first before it can remove body.
Title: Re: OpenXcom Extended
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. :)
Title: Re: OpenXcom Extended
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!
Title: Re: OpenXcom Extended
Post by: Yankes on October 11, 2014, 12:43:26 pm
I remember that, simply I didn't do any new release yet to include it ;P In next version I will do it (that will be today or tomorrow).

You copied it wrong way, without line breaks and spaces its useless.
Proper rul should look like:
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).
Title: Re: OpenXcom Extended
Post by: Yankes on October 11, 2014, 07:56:41 pm
New version is ready.

Damage can now affect TU (Flashbang :D), Energy, Morale (with bravery resistance) and can you can ignore default morale lose form dmg.
TU Throw and Prime cost in % for items.
Fixed weapons for armors.

Title: Re: OpenXcom Extended
Post by: new_civilian on October 12, 2014, 05:23:20 pm
Gee, wonderful! You guys rock!  :) *happy*
Title: Re: OpenXcom Extended
Post by: Sturm on October 14, 2014, 04:58:14 am
I will think about this. This probably will be easy to do.
Probably later ;P Its because my primary goal is create mod platform not obey original rules. I already made some changes that should no be in basic OXC.
Example of this is how I handle unconscious unit under explosion, In my version explosion must kill unit first before it can remove body.
The reverse could be cool too. Explosions being able to cause body/equipment destruction on living soldiers.
Title: Re: OpenXcom Extended
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.
Title: Re: OpenXcom Extended
Post by: new_civilian on October 14, 2014, 04:24:18 pm
Excellent idea, Dioxine! You are one creative person.

Some feedback after testing the exe:

You converted me. Now I no longer care about any official exes (and other exes) anymore, THIS is the way to go.
Dioxine and very other megamod-maker: Switch to this exe, it adds so many possibilities.

And best off all: you can just add one more ntiny rulset with all the Extended- changes  and leave the rest of your mods unaltered, that's what I made in my personal mod combination.

One of the coolest (and easy to miss) changes is the ability to make a weapon wound enemies, I simply added those to the shotguns and similar weapons. Also great: You can add a morale damge bonus to e.g. Incendiary weapons, I'm burning, help meeeeee.  ;D Ther zombie-proof armor you always wanted? here you go. Tired of your Enforcer-robots turning into Zombies after Chryssalid-attacks? Just use this exe and make their armour immune. Ever wanted a dual-wielding armor with integrated weapons?  and and and.....


wow.


Really, I do not know what to say, this is just plain awesome. and everything works so far! Have to test the ALTSPRITE feature today, I added a prined graphic to my Naymore mod for that...

Anyway, a BIG thanks to Yankes and everyone else participating in this!
Title: Re: OpenXcom Extended
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 :)
Title: Re: OpenXcom Extended
Post by: Yankes on October 14, 2014, 08:02:17 pm
Thanks for that civilian :)

Definitely - it'd make "nuke"-type weapons more balanced and realistic (Blaster but also literal nukes), by destroying all the loot. Right now a Blaster can be used safely, since a single explosion, no matter how powerful, can only kill an unit and the damage doesn't carry over to the corpse/equipment.
I didnt do that only because I tried sneak in to master branch. Now I can revisit that code and alter it more.
Any suggestion how it should work exactly? One way of handling it is apply all over kill damage multiplied by "ToItem" to corpse and items. If damage is grater than durability of item then item is removed and corpse not spawn.

Another changes I plane to add is that fire & smoke affect stunned units.
Title: Re: OpenXcom Extended
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?
Title: Re: OpenXcom Extended
Post by: new_civilian on October 15, 2014, 04:41:56 pm
Just tested the ALTSPRITE features and the dual-wielding personal armor concept and both work fine!  :)
This is so awesome! *happy*

And the craftweapon types work fine, too. I split my weapons into three teirs (eras) and it worked w/o the slightest problem, really good work!

One thing that surprised me (and scared the shit out of me) was the damage that the alien PSI attacks do by default. But it was as easy as adding tthree lines of code to my ruleset and the problem was corrected.
The default setting makes alien psi VERY deadly. No range limit, no ammo limit, NO defense possibility and worst of all: they do not need to see you (if you don't use the LOS option)... I swear that was one scary mission before I could go back to base and edit the rul file  ;D
The scariest mission I played in several years actually.

Talking about features: After trying the REALVISION exe some weeks ago, would it make sense to add a VisibilityatDay entry as well? I am still not sure about this. The REALVISION exe was quite a performance hog on my PC... the game basically stopped each step a unit made so...

*Update: tested most, maybe all damagemodifiers and they work! I even managed to make a Stasis-Grenade, removing all the TUs from the hit unit, impressive work redv and Yankes.
Title: Re: OpenXcom Extended
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?
Title: Re: OpenXcom Extended
Post by: new_civilian on October 18, 2014, 01:08:45 pm
Sorry, no unit graphics, I tested the Primed Grenade feature with a custom icon.

Yankes, I found a bug, PM'ed you about it. Will be offline for some days, so i can not report for that time.  :-\

Btw, is it possible to add one thing that I really miss when modding X-Com: An exclusion function for researches? e.g. If you research this weapon theme you will be unable to research another one, forcing you to make decisions e.g. should I go for  Laser or Gauss or Heat-Ray this time? This would give the player a reason to play another campaign, testing all the weapons by themselves and not all at once...

And it would unclog the research selection screen...  :)

CU soon-ish...
Title: Re: OpenXcom Extended
Post by: Yankes on October 31, 2014, 12:21:08 am
Obliterate!
https://www.youtube.com/watch?v=MnKh1nU4XZU
Title: Re: OpenXcom Extended
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?
Title: Re: OpenXcom Extended
Post by: Yankes on October 31, 2014, 12:40:38 am
Right now it's only based on damage dealt to unit. Threshold now is half of max hp. If negative hp move past it, unit don't leave corpse behind.
Title: Re: OpenXcom Extended
Post by: ivandogovich on October 31, 2014, 12:43:43 am
So in theory, even mundane weapons might be able to obliterate something?
Title: Re: OpenXcom Extended
Post by: Yankes on October 31, 2014, 01:15:44 am
Yes if it done enough damage in final hit.
Title: Re: OpenXcom Extended
Post by: arrakis69ct on November 01, 2014, 12:24:58 am
Uppps economy crisis. No body no money XD

Enviado desde mi LG-D802 mediante Tapatalk

Title: Re: OpenXcom Extended
Post by: XOps on November 01, 2014, 01:34:18 am
Very nice! Does it use custom animation frames for each death as in a modder would have to add three extra death frames per unit sprite sheet or is it an engine effect?
Title: Re: OpenXcom Extended
Post by: Yankes on November 01, 2014, 11:43:01 am
Engine effect. You don't need add anything. Funny thing this is that I don't know why it behave that way :D I excepted it should made all colors turn black but it instead made all transparent. My overall goal was crate same effect but I didn't except it will work without creating special function doing this.
Title: Re: OpenXcom Extended
Post by: Yankes on November 01, 2014, 01:28:49 pm
New version is ready.

Main change is overkill damage. Damage can now pass to negative values, if negative damage will be greater than half of max hp then unit evaporate and don't leave corpse or spawn new unit. Items can be destroyed then too.
This can be turn off in damage type by property "IgnoreOverKill", this is turn off by AP and MELEE damage.
Title: Re: OpenXcom Extended
Post by: new_civilian on November 01, 2014, 02:45:26 pm
Awesome!  :)  Downloaded it atm, my free weekend is ruined now  ;D

edit: tested it the whole day and night and it works like a charm! That overkill feature is so cool.  8)
Oh and nice to see you found the grenade problem thingie and corrected it!  ;)

Modder "tip": Regarding the ALTSPRITE function: After a while of testing several things I think that simply adding a tiny yellow X to the graphics works best for me, it is easily doable and visible. That and you do NOT need new graphics which makes things easier and safer in the battlefield.  ;)
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on November 07, 2014, 04:46:51 pm
Just realized that the ability of fixed weapons in armor allows for armed civilians. Now they could wield pistols or combat knifes.... :)

*have to test this!*

edit: Doesn't work.  :-[ It seems to be a original OpenXcom problem, though.
Title: Re: [EXE] OpenXcom Extended
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.... :)

*have to test this!*

edit: Doesn't work.  :-[ It seems to be a original OpenXcom problem, though.
I recently walked close to that code, and I can confirm that civilians don't load any items. I could add this but there is bigger problem. Civilians don't have any AI to use weapons. This will probably require lot of work to fix it.

Meanwhile I added interaction of stunned unit with fire and no-explosive weapons. Additionally I fix spawning code of chryssalid, it can now spawn with plasma rifle and don't require special weapon type.

Exe will be ready when I finish small overhaul of psi-weapons, codename "Psionic Storm" :D
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on November 14, 2014, 12:25:03 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...

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.
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on November 14, 2014, 07:10:15 pm
i have simple idea:

- additional stat for weapon that would modify power damage from its ammo from range 0 to N%

sample of usage:

- aliens have 3 weapons pistol, rifle and heavy
- aliens have single clip that match all weapons
- aliens have stronger clip that has better power similar to poison A B C from apocalypse. Each clip has different ammo but there are also 3 different weapons. Normally this would require 9 ammo clips which is somehow redundant

Tom
Title: Re: [EXE] OpenXcom Extended
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...

I even tried 0.00001 as a damage but that didn`t work either. Same for the alien side. I wondered why none of my troops got ever panicked or controlled through the whole game until I was able to use PSI attacks myself. ;D
A soldier with 100 PSI strength and 84 PSI skill couldn't do anything even when standing right next to the alien.
psi weapon don't do damage form power, it's should treat this as bonus to "MC" chance, at least I tried do it in that way. Right now I'm busy and can't check out this now. Probably in next week I will be able find some time to fix it.
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on November 17, 2014, 04:56:01 pm
Ah sorry for my somewhat unclear description: What I mean is: you gave the PSI-weapons a 0.02 damage by default. I wanted to get rid of that so I set the number to 0.0. That`s when they stopped to work.

I did not add an additional bonus, I mereley changed the default (invisible, hard-coded one) to zero.

And yes, take your time, I`m more than happy with the current version.  8)
Title: Re: [EXE] OpenXcom Extended
Post by: robin on November 17, 2014, 07:14:55 pm
Does OXC Extended support "dual wielding" tanks?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 23, 2014, 05:17:39 am
New version is ready.

Updated to recent warboy changes.
I fixed bug with psi amp that deal damage to unit, in long run it will be feature but right now is bug (you still do this if you change psiamp damage type).
Stunned unit can be kill by normal weapon if you hit place where its lay. Fire affect them too.
You can change default alien psi weapon per armor or race (its share slot with melee weapon).

Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on November 23, 2014, 05:34:41 am
Nice changes! I really gotta get around to using your version (but I've had enough issues compiling nightlies, I'm not ready yet for something else...).

Do you think it would be possible to code things such that the alien psi-weapon can be given in the itemlevels?

That would allow mods where the psi-powers vary with time, even within a given race. I want to make a mod where aliens get a few psi-weapons:

- one that requires LoS, so it not a major factor for beginning players fighting sectoids
- one that doesn't, but has a large TU cost for mid game. You can be attacked anywhere/anytime BUT it won't be 10 times a turn.
- one that doesn't require LoS and has a really low TU cost, making psi-powers a real threat (or at least mitigating the waste of TUs it is for aliens when they try to use psi-powers against hand-picked, psi-hardened XCom operatives)
Title: Re: [EXE] OpenXcom Extended
Post by: robin on November 23, 2014, 11:36:45 am
Dumb question.

Does the extended exe work as a "launcher" for vanilla exe, or is it "its own exe", replacing vanilla exe (do I need to rename it "openxcom.exe" after deleting vanilla exe?)?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 23, 2014, 02:11:28 pm
@Arthanor right now is build in alien unit, it can't be easy altered by itemlevels. One way to easy fix that is give aliens normal psiamp as weapon and allow alien AI to use it.

@robin this is separate exe with different name, after installing it you can chose which exe to run. Both exe can live together fine.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on November 23, 2014, 08:23:18 pm
That would be cool. I wish someone could do that  :D
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 03, 2014, 02:02:23 am
New shining things:

Armor can have build in regeneration.
You can custom load and unload cost (+ you need pay cost of moving items around inventory).
You can unprime grenade using unload button (I leave requirement for 2 empty hands as feature).

My next goal will be continuation of altering psi weapons.
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on December 03, 2014, 03:17:23 am
I have a request.

Custom medkit weapons, that is to say I want an item type that allows me to define a ranged weapon with a med kit  stim option and be able to give it a melee damage

I want to make "detention equipment" Which is like three items in one with the goal of stunning/ capturing someone. Which would actually be a combination of a few items shown in a 2x3 item area.

-A taser for doing stun damage up to four squares away
-A Syringe for dosing an operative full of Thorazine
-Duct-Tape\zip ties\ blindfold...for flavor :)
-A truncheon for beating them unconscious

How many times have you been like "OK, I really don't want to kill you, but I need you NOT to be taken over by aliens." Thus I want to be able to taze, inject, beat senseless, hog tie and blindfold troublesome operatives.

**edit** new idea came to me about 15 minutes after I posted... no need for a new post!**

I would like a  "We can now buy" screen to pop-up if I complete a research project if I can buy something my scientists or engineers didn't think to purchase before.

A few examples...

I would like to be able to research let's say "alien circuitry" from the Xops mod and learn about cool alien circuit designs that I can't replicate, but still gained insight into how the aliens do things and make some breakthroughs. What if I could make inferior knock-offs to use in human equipment and told telecommunications company that they could have the tech if when they fabricate it I can buy it from them?

or

What if my guys discover that the alien abduction equipment is really good for DNA analysis and creating custom drugs for a person almost instantly? I call Merck and they give me bad ass combat drugs with a smile for cluing them in.

or

My scientists discover a way to make Elerium go further by refining it with nuclear waste. I suddenly need to buy nuclear waste and use it to refine Elerium... cuz my engineers said so.

thoughts?
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 03, 2014, 09:24:00 am
Yankes

Please consider following new features:

1) feature (global variable) to penalty players to use two hand weapons and still use grenandes etc ? This is quite simple to implement.

https://openxcom.org/forum/index.php?topic=3174.0

If move item FROM / TO hand and second hand is taken and item is two handed, then double or triple cost to move this item TO or FROM second free hand. This double or triple would be modifier. Default value would be 1.0.

This should be simple to implement but this could broke balance of one - two hands weapons.

2) feature for terrains / biomes that changes its "texture" and "battlescapeID" based on time of year.

https://openxcom.org/forum/index.php?topic=3160.0

 What we need is a new field for terrain. Normally there is "terrainID" for terrain. Lets add an array with 12 items that would simulate change of terrain per months. And when EndMonth trigger is run then change terrain behavior based on this array.

terrainID = 3
terrainMatrix = [3,3,3,3,3,3,5,5,5,5,5,5]

So this terrain is "3" in Jan-Jun but is 5 in Jul-Dec. This works both for visual effect and battlescape. Default value would be same as standard terrainID for all months.

This should be tricky to implement i think.

3) feature about obsolete technology which works exactly opposite to required. Below is pseudo code:

https://openxcom.org/forum/index.php?topic=3155.0

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
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 03, 2014, 11:57:40 pm
I have a request.

Custom medkit weapons, that is to say I want an item type that allows me to define a ranged weapon with a med kit  stim option and be able to give it a melee damage

I want to make "detention equipment" Which is like three items in one with the goal of stunning/ capturing someone. Which would actually be a combination of a few items shown in a 2x3 item area.

-A taser for doing stun damage up to four squares away
-A Syringe for dosing an operative full of Thorazine
-Duct-Tape\zip ties\ blindfold...for flavor :)
-A truncheon for beating them unconscious

How many times have you been like "OK, I really don't want to kill you, but I need you NOT to be taken over by aliens." Thus I want to be able to taze, inject, beat senseless, hog tie and blindfold troublesome operatives.

**edit** new idea came to me about 15 minutes after I posted... no need for a new post!**

I would like a  "We can now buy" screen to pop-up if I complete a research project if I can buy something my scientists or engineers didn't think to purchase before.

A few examples...

I would like to be able to research let's say "alien circuitry" from the Xops mod and learn about cool alien circuit designs that I can't replicate, but still gained insight into how the aliens do things and make some breakthroughs. What if I could make inferior knock-offs to use in human equipment and told telecommunications company that they could have the tech if when they fabricate it I can buy it from them?

or

What if my guys discover that the alien abduction equipment is really good for DNA analysis and creating custom drugs for a person almost instantly? I call Merck and they give me bad ass combat drugs with a smile for cluing them in.

or

My scientists discover a way to make Elerium go further by refining it with nuclear waste. I suddenly need to buy nuclear waste and use it to refine Elerium... cuz my engineers said so.

thoughts?
I don't think that mixing item types is good idea, most of this features you request are possible as separate weapons.
Weapon damage can affect "hp", "tu", "energy" and "morale" in positive or negative way. You could create pistol that will kickup stunned unit form ground simply shooting place where unit lie.
Its probably too much code change for so small functionality.

To next thing, I would prefer don't touch UI at all. To do it properly it would require adding new language strings.
This will cause multiple problems I would prefer avoid. But functionality you require is already implemented (except of UI part).
Availability of items in buy windows can depend on research state.

Yankes

Please consider following new features:

1) feature (global variable) to penalty players to use two hand weapons and still use grenandes etc ? This is quite simple to implement.

https://openxcom.org/forum/index.php?topic=3174.0

If move item FROM / TO hand and second hand is taken and item is two handed, then double or triple cost to move this item TO or FROM second free hand. This double or triple would be modifier. Default value would be 1.0.

This should be simple to implement but this could broke balance of one - two hands weapons.

2) feature for terrains / biomes that changes its "texture" and "battlescapeID" based on time of year.

https://openxcom.org/forum/index.php?topic=3160.0

 What we need is a new field for terrain. Normally there is "terrainID" for terrain. Lets add an array with 12 items that would simulate change of terrain per months. And when EndMonth trigger is run then change terrain behavior based on this array.

terrainID = 3
terrainMatrix = [3,3,3,3,3,3,5,5,5,5,5,5]

So this terrain is "3" in Jan-Jun but is 5 in Jul-Dec. This works both for visual effect and battlescape. Default value would be same as standard terrainID for all months.

This should be tricky to implement i think.

3) feature about obsolete technology which works exactly opposite to required. Below is pseudo code:

https://openxcom.org/forum/index.php?topic=3155.0

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
1) I think it could complicate too much inventory management, but if you could create clean implementation of this I can merge it to my branch (it could be defined per weapon, because some weapons could be harder to handle).
2) Interesting idea, but I have problem with transition form one state to another. I have some possible solutions for this but all will be probably very complex.
3) Can be done.
4) I didn't touch that code region jet.
5) I prefer avoid UI stuff.
6) Interesting idea, It could be simply implemented by two YAML arrays of pixel colors. I think it could be expand to human crafts too.
7) & 8 ) Can be done, but I would prefer focusing on something different.
9) Can be done.
10) Again its require change in UI.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: robin on December 04, 2014, 12:13:45 am
Armor can have build in regeneration.
Alien armors too?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 04, 2014, 12:42:31 am
Please provide a working example so I may replicate it.

-HH
from first post:
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).
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on December 04, 2014, 03:03:52 am
Thanks... My weekend is shot thanks to you...  ;D
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 04, 2014, 12:46:29 pm
1) is it possible to set required technology to USE item in battlescape and to BUILD item by engineers as two separate technologies ?

if not can we add this ?

2) Does aliens consider effective chance to hit when using different accuracy modifiers like aimRange, snapRange etc ? I found that aliens try to shoot using shotgun outside max range and using sniper rifle inside min range. In both cases this cripples alien tactics a lot.

Would be nice to add simple check what should be current accuracy and theoretical accuracy in few closest nodes. In case accuracy is low try to move to another node first before fire. This would work both for min and max Range. This would be cheating for aliens but would simulate proper usage of weapons based on their range. This could be turn on / off as option just like SneakyAI.

3) what about option to auto buy items if they are not available to refuel / reload crafts ? It is still pain in the arse to go to base to buy single stingray missile because it lacks. This would require flag to item autoBuy and if player has money and there is enough store in the base then instead of display window "not enough" then just buy it.

4) would be nice to have feature to CREATE ITEM on the field where bullet hits terrain. Item would be created AFTER explosion if any exist. I can imagine a flare launcher for example but there are more examples. This is already implemented in create map block so shouldn't be problem.

5) would be nice to have feature to CREATE ITEM on field that unit have left during movement. This is already implemented for one alien terror unit but i think is not configurable for other units.

6) feature based on global variable with default value of 0, that simulates Half-life time of Elerium-115. Every start of month player is loosing N% of its elerium-115 cargo just like decay of radioactive isotopes. So value of 0.1 would mean loss of 10%. Script could be very simple, just add in newMonth trigger check of alien fuel item and deduct N% from it. With default value of 0 this will not harm standard game.

7) acceleration based dogfights. Once again global parameters that control this aspect of the game. It defines percentage change of default speed based on difference of acceleration between UFO and x-com craft. Default value is 0.0.

Avenger with acceleration of 10 is fighting battleship with acceleration of 5. Default speed of UFO during dogfight is 4 / -2. In case of our parameter is set to 0.05 then we have 1.25 * 4 and 0.75 * -2 in the game.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 04, 2014, 10:10:29 pm
1) Yes, it's in basic OXC
2) This probably should be fix in basic OXC
3) This will require UI changes, and this is more as gameplay improvements than mod (This could be sneak in to basic OXC).
4) & 5) And item will do what? This will require additional changes too to have any interesting gameplay effect.
6) This should be more per item type, corpses and aliens could "decay" too. But I don't think that will be so easy to implements. Do you remember monthly payment exploit in original ufo?
Title: Re: [EXE] OpenXcom Extended
Post by: yrizoud on December 05, 2014, 12:05:27 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 ?
Title: Re: [EXE] OpenXcom Extended
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!

:)
Title: Re: [EXE] OpenXcom Extended
Post by: yrizoud on December 05, 2014, 10:12:36 am
I mean, how do you handle the conflict when the ship is transferred in a different base, the soldier is assigned to a different ship, or already re-equipped differently ?
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 05, 2014, 11:17:02 am
i just proposed a solution to a common problem
i am not saying its simple to implement or if it does cause more problems then it solves :)

For example i just make a test how acceleration impact dogfight and it works great from tactics point of view but on the other hand completely change airbone warfare and force to create new balance for both x-com crafts and alien ufos.
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 05, 2014, 08:27:56 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 ?

Thanks
Title: Re: [EXE] OpenXcom Extended
Post by: robin on December 05, 2014, 09:34:17 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).
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 09, 2014, 02:19:11 pm
Another simple idea regarding base defense:

1) Let defenses facilities have number of shots per wave with default value of 1. Each is calculated separately but can be weaker then original. Grav shield works as usual. Main reason is to differentiate different buildings as standard ones are very similar to each other. Expected value of damage would be the same. Now buildings differs mainly by sound as they are not even shown on base defense screen.
2) Would be nice to have information about damage done to alien ship in percentage, not just info about hit / miss.
3) When mission starts and UFO is damaged then kill proportional number of aliens based on damage. 10% of destroyed hull would mean 10% of killed alien units during battlescape. They can be just killed after mission is generated with bodies exist on the battlescape. This could be configurable by a flag / option "Lethal base defenses" as a bool.
4) Set delay between weapons are fired per facility as for now this delay is hardcoded to be 250 or 333 ms.
5) Let facilities consume ammo if defined. If no ammo is available in stores then add message "No ammo". Default value would be no ammo is required.

2a) If percentage information about UFO is impossible then at least create a more advanced UFO status that could be displayed in future on other screens. Now its just DESTROYED / CRUSHED / LANDED / FLYING. 

100-90%   no damage (at least we know that UFO is tough)
70-90%     light damage (at least we know we done some damage to UFO)
50-70%     medium damage (at least we know that it is closed to shot down UFO)
below 50% -> normally is crushed but here would be heavily damaged until destroyed

I know this base defense is very very very small part of the game but on the other hand all those customizations are very simple to implement in single file.

Other thing is would be nice to have a flag for an item that says "IS DESIGNED TO BE THROWN". This would reduce range or / and arc of thrown items that are not designed to do it by some percentage. By default all items are designed to be thrown so no modifier is applied. For example grenade has weight of 3 and high explosive of 8, but the second one never was designed to be thrown, which means for purpose of throwing we should treat its weight not as 8 but as 12 for example.
Title: Re: [EXE] OpenXcom Extended
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 ?

Thanks
I can draw you some. I think you should go larger than 5x5 though. Anything smaller than 9x9 is difficult to see in the higher resolutions, and the originals are already 3x3 so might as well make a worthwhile change.
Title: Re: [EXE] OpenXcom Extended
Post by: The Reaver of Darkness on December 13, 2014, 05:00:18 pm
(https://i.imgur.com/uxHYXbm.png)
Here I have the 9 geoscape icons I could think of rendered in 9x9 resolution. I made three versions:

1.) standard high-resolution
2.) classic low-resolution (built for high resolution setting)
3.) stylized (courtesy of my mediocre art skills)
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 13, 2014, 05:16:59 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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 13, 2014, 05:52:46 pm
I thin is better to stick to small graphic 3x3 or max 5x5. Another thing is to use different shapes not size to represent different crafts.
Something like that:
Code: [Select]
>small scout (3x3)

 #

>medium scout (3x3)
 #
# #

>large scout (3x3)
 #
# #
 #
>somthing diffrent (3x3)
###
# #
 #
>biggest alien craft (5x5)

 # # #
  # #
   #

Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 14, 2014, 02:55:37 pm
actually if craft / ufo is not 3x3 or 5x5 then it will be drawn not in the middle of sprite, this will look strange when combine with line that shows craft path.
Title: Re: [EXE] OpenXcom Extended
Post by: The Reaver of Darkness on December 14, 2014, 05:30:23 pm
Well it's a bit difficult to make convincing icons that small. Here's some icons to represent the five UFO sizes (along with the X-Com craft from last time):
(https://i.imgur.com/HGctHBB.png)

This leaves the very small at 1x1 but if you can add transparency, you can make it a 3x3. Or if you leave it 1x1 it should still display approximately correctly.
Title: Re: [EXE] OpenXcom Extended
Post by: The Reaver of Darkness on December 14, 2014, 08:50:23 pm
Another simple idea regarding base defense:

100-90%   no damage (at least we know that UFO is tough)
70-90%     light damage (at least we know we done some damage to UFO)
50-70%     medium damage (at least we know that it is closed to shot down UFO)
below 50% -> normally is crushed but here would be heavily damaged until destroyed

I know this base defense is very very very small part of the game but on the other hand all those customizations are very simple to implement in single file.
I think this is a nice idea. I'd go a step further and make it so that partially damaged UFOs drop fewer alive troops into your base. Or perhaps some of the times you get attacked, they use a smaller ship. Without any update like this, base defense facilities are useless until you have enough to shoot down a ship, which means that missile and laser defense are pretty much useless altogether.

Perhaps your base should get attacked much earlier in the game and more frequently, by small craft. With a missile defense or two, you could knock the smallest ones out of the sky and focus only on those that matter.
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 16, 2014, 02:31:19 pm
another small thing

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.
Title: Re: [EXE] OpenXcom Extended
Post by: Warboy1982 on December 16, 2014, 03:10:07 pm
you can already do that. those are just the vanilla values.
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 16, 2014, 05:18:21 pm
sorry Warboy1982 i think i need to check sources first before posting :)

on the other side, even when i am tech person i do not want to know how the sausage is made not kill all the fun from playing the game :)
Title: Re: [EXE] OpenXcom Extended
Post by: Warboy1982 on December 16, 2014, 10:32:26 pm
hah!
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 17, 2014, 08:50:35 pm
is it possible to merge extended version into vanilla with additional flag that turns features on / off just like other advanced features (not mods) like UFO extender ?

and why not ?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 17, 2014, 10:11:00 pm
It will be hard, I change many thing to made my stuff work, and another thing is that Warboy didn't like to maintain code that go in opposite direction that goal of OXC.
This separation is positive because I could go further than basic codebase would allow. Another thing is if I f*** up and destabilize code then only my mod would be abandon. If it was master branch then that could kill whole project, because every one depend on that its work properly.
Title: Re: [EXE] OpenXcom Extended
Post by: Warboy1982 on December 18, 2014, 06:41:46 am
wow, that's a really good rationale.
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 18, 2014, 02:05:03 pm
Thanks for detailed explanation about extended version.

I wonder can we then create "external version" that main goal would be NOT adding more functionality to the source code but move hardcoded stuff to the ruleset so moders could change it. This would be then integrated to vanilla version without break down compatibility. This also would need to have fresh documentation updated on regular bases in the wiki.

Try to rename STR_BATTLESHIP to something and it will break game on retaliation mission for example. Instead of this other ship could be used or even a list of ships to pick one randomly. Battleship is very strong and have big crew. Imagine terror ship that is easy to destroy but has very large crew during attack. This small change would actually bring value to the game to use low tier defense facilities once again.

Tom
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on December 18, 2014, 10:56:45 pm
Now back to extended version....  feel free to implement it or. I just post ideas that might have nice value to moders.

In "UFO Trajectories" there are waypoints defined as [zone, altitude, speed]

Altitude means:
0 - Ground
1 - Very Low
2 - Low
3 - High
4 - Very High

Would be nice to have also
-1 - Force crash of UFO just like it was shot down, as this might be useful. Something similar was implemented in Ufo Extender i think... force some Scouts to crash randomly. 
5 - leave Earth orbit and ends this mission without score for alien. I mean not just this UFO but all future UFOs from this mission.

Would be nice to have also one more parameter [zone, altitude, speed, chanceToSkip] with default value of 0. For example harvest mission could land once, twice or never. That would enhance player experience even in vanilla game.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 19, 2014, 02:19:45 am
New version uploaded.

3 changes:

Option for Ufo2000 damage type (you can damage armor even with weak shoots).
Bonus to Accuracy/Damage/Melee hit chance be based on most of unit basic stats.
Psi-amp can now cause direct damage, you can crate fireball, pyrokinetic or psistorm attack (Alien could do it too).
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 07, 2015, 08:27:26 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.
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout 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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 10, 2015, 06:52:25 pm
Ok I find some bugs, I will fix them.

[ps]

I find only bug with doors, psi attacks work fine, what version of OXC did you use for base? Remember that I did not yet update it to latest nightly.
Do you add some custom ruleset that could break my mod?
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on February 11, 2015, 01:39:28 am
Is possible  I may have upgraded over the latest nightly then to extended :/

lemme try again
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 15, 2015, 09:03:17 pm
Extended version is up to date with nightly now (2015-02-15).

btw tollworkout, do you have still this bug?
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on February 15, 2015, 09:47:02 pm
is working fine NO more problems. i tried all types of default psionics i tied mind controling debug base defense terror missions with mods etc . works fine. :D
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 16, 2015, 01:19:56 am
good :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 22, 2015, 06:28:26 pm
Another update

Version based on 2015-02-22 nightly.

Armor can change overkill damage threshold.

Stats bonus can calculate polynomial from values. This will allow for no linear relation between bonus and basic stat value.
Right now supported is square and cube of value.

Stats bonus can access curret hp, energy, tu and morale.
Tou can add penalty for low morale to accuracy.
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on March 02, 2015, 09:11:34 am
yankes can you upload you binary to the forum seems mods is down for time being. I wanted to test out this ruleset i was thinking of building based on your changes.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 02, 2015, 07:27:37 pm
https://www.mediafire.com/download/c66j0nop2sm7gx8/OpenXcomEx.zip
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on March 02, 2015, 08:52:23 pm
thank you sir
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 05, 2015, 01:04:41 am
Small update with recent SupSuper changes to regions.

[PS]

My next goal will be requirements for research and production based on available buildings in base.
This will allow for research to require special building like "physic laboratories" present in base to start research plasma weapons.
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on March 05, 2015, 01:54:54 am
yankes you should make a custom training facility that turns item X into item Y for ex can turn soldiers into mecs or can turn soldiers into better soldiers or turns live aliens into soldiers etc.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 06, 2015, 07:20:06 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.
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout 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 :)
Title: Re: [EXE] OpenXcom Extended
Post by: Mono on March 08, 2015, 06:15:48 pm
Hy Yankes!
Whit OXE I can finally trash my own armors during battle tanks to your damageAlter property.
I love your work!  :D

I'm reading the pedia at https://www.ufopaedia.org/index.php?title=OBDATA.DAT#Grenades (https://www.ufopaedia.org/index.php?title=OBDATA.DAT#Grenades)
(setting a pre-primed bomb under the UFO Power Source), but I was unable to replicate this
behaviour. There is a way to set some kind of timed auto-destruction in battlescape?
If not, may you be interested in adding one to OXE?

I also have a second request (I'm a greedy person   :P)
Can be possible for a weapon to inflict random damage to the user?
What I have in mind is a possibility for psi-amp of doing 1 or 2 hp damage to my own soldier,
but this can also be used for a 1/1000 chance for a weapons to explode OR for an object to
inflict negative damage (healing) the user.
(healthUse, similar to the energyUse property you add to items ruleset)

well, my 2 cents anyway.
Thanks for your time and work!
Title: Re: [EXE] OpenXcom Extended
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)
(setting a pre-primed bomb under the UFO Power Source), but I was unable to replicate this
behaviour. There is a way to set some kind of timed auto-destruction in battlescape?
If not, may you be interested in adding one to OXE?
You read wrong ufopaedia article :> Hack form UFO don't work in OpenXcom, its have its own set of hacks :)
And about implementation, its depend on required functionality (how exactly it should behave), if is only one "if" change in code then I will do it.
If it require lot of changes I will probably pass. Right now I will give it 70% chance to be implement.

Quote
I also have a second request (I'm a greedy person   :P)
Can be possible for a weapon to inflict random damage to the user?
What I have in mind is a possibility for psi-amp of doing 1 or 2 hp damage to my own soldier,
but this can also be used for a 1/1000 chance for a weapons to explode OR for an object to
inflict negative damage (healing) the user.
(healthUse, similar to the energyUse property you add to items ruleset)
Only thing that prevent me form doing it is error message when you don't have enough hp to use item.
To do it properly I should add string in all languages that are supported by OpenXcom. This is a lot of work that I prefer avoid.
Only way I see doing it is throw all responsibility onto modders to provide require texts if they use it, but this is lazy solution.

Aside of that, I except that in some day I will do this when I add `energyUse`. Most of code was refactored to support `healthUse` and `moraleUse`,
but because previous problem I didn't move that far.

If I did add this, cost would be flat cost. It would work exactly like current `energyUse`.  Every use would reduce your `hp` by some value like `3` or `42` with no random.
Title: Re: [EXE] OpenXcom Extended
Post by: Mono on March 08, 2015, 11:41:23 pm
tank you for the quick response!

What I tried to do is add a custom alien grenade in terrains.rul (elerium in UBASE is added
this way), on top of the elerium, and then messing around whit the item properties: battleType: 2 (Ammo), clipSize: 25 (turns left), meleePower: 25 (also turns left) as described on the Pedia.
I was thinking that the rulesets was used the same way as OBDATA.DAT is used on original game.
My fault  :-[
In short, what I ask you (if you are willing to do it) is to add a way to insert a pre-primed bomb
in the battlescape. Then modders can place this item via terrains.rul.
Citing the Pedia for possible usage:
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"?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 09, 2015, 12:32:49 am
If this "grenade" is one time use and you can't bring it to fight then I could do it.
I need first check how best is to handle this. I would prefer avoid situations when its spawn in base defense mission (because you get some) and start exploding obliterating your facilities. Another thing is if we allow aliens equip this too?

Overall I will think about this but meanwhile I need do some different work like updating my branch to official one. This will take some work, because Warboy change lot of code that I change in my branch too.

And for messages, this fall in lazy category too ;P
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on March 09, 2015, 02:56:50 am
The ability to spawn a primed grenade (or other explosive) could be cool.

The previously mentioned exploding power sources could turn the game into a rush to eliminate aliens on a craft UFO before the self-destruct countdown runs out, which is such a classic from sci-fi that it really deserves to be doable. Sectoid Leader to his Engineer: "We are being overrun! Set the Elerium Engine to overload!!"; "Overload in 15 minutes, Sir!"

Or set the radius to one and just make it even harder to get Elerium out of crash sites..

Interesting, in a nasty, masochistic way!
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 09, 2015, 08:51:19 pm
New version available

Killer feature is that buildings can now have dependency chain. You can require that to build one building you need have two other available.
Same with research and manufacture, you need specific buildings in base to starts projects.

Some examples:
To do alien autopsy you need have special building Prosectorium in that base.
You can manufacture E-115 but to do that you need build LHC in your base that will drain lot of power bills :)

Only limitation is that you need only one building of that type to benefice from it.

Rest of changes added in this version is change of handling throwing ad hitting using twohanded weapons, now they have penalty like while shooting.
Another change is prime and throw action can be configure to use flat TU costs.
Title: Re: [EXE] OpenXcom Extended
Post by: Mono on March 11, 2015, 02:40:48 am
wonderful new possibilities... Thank you.
For my part, I just started learning how to mod and I don't think I will use more than 5% of the freedom offered by OXE.

New buildings are a call for longer and longer games and unlike items or armors, they need talented modders for new maps and new routes. Out of my reach. But I will wait for new resources to stole  :)

Can I pester you a little about "lazy solutions?" ::)
Referring to the previous posts on "healthUse" and "moraleUse":
what if the soldier that don't have enough hp to use item will simply be knocked down stunned (attack not performed)? Is this reasonable?
Ok I will not open the matter anymore, I swear!

Thank you for your work!
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 11, 2015, 07:58:57 pm
Can I pester you a little about "lazy solutions?" ::)
Referring to the previous posts on "healthUse" and "moraleUse":
what if the soldier that don't have enough hp to use item will simply be knocked down stunned (attack not performed)? Is this reasonable?
Ok I will not open the matter anymore, I swear!

Thank you for your work!
This will complicate code a lot, it's because I need add handing of suicide after every place where is spend resource.
If you really want it, I will add this (when I will have some free time) but all burden of providing messages (even in English) will be on you and other people that want use it.
Title: Re: [EXE] OpenXcom Extended
Post by: XOps on March 12, 2015, 04:57:34 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?
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on March 12, 2015, 05:10:23 am
i got this badass openxcm extended idea i been thinking about i m gonna do it one day. is just a simple but COOL mod . i gotta re-read the  main page to make sure is possible.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on March 18, 2015, 06:51:30 pm
Hmm... if this hasn't been implemented yet, I have an idea that could add to the complexity of weapons:

- "Dropoff" of explosion. Afaik, currently the explosive power drops by 10 per every tile travelled. It'd be great to be able to edit this value via ammo/grenade entry, so you could have large explosions without a "sharp kill zone edge" (as simply cutting the blast radius works if you want to achieve smaller explosion). An ideal would be an option to make the explosion lose % of initial power with inversed square root, but that might be a bit confusing and maybe needless :)

Btw, do airborne Incendiary explosions work in OXCom Extended? In the normal build, hitting an airborne target with Incendiary simply does nothing. Is there as simple solution to this problem? An ideal would be the fire to "drop down", so perhaps Incendiaries should set the target on fire + cause an incendiary explosion on the ground, with the power reduced by the altitude difference...
Title: Re: [EXE] OpenXcom Extended
Post by: Ridаn on March 18, 2015, 07:07:00 pm
Would it be possible to make a med-kit item that targets the user?

Sure hope that after completing TFTD development team would consider integrating all those goodies into a main branch. Keep up the good work.
Title: Re: [EXE] OpenXcom Extended
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:

- "Dropoff" of explosion. Afaik, currently the explosive power drops by 10 per every tile travelled. It'd be great to be able to edit this value via ammo/grenade entry, so you could have large explosions without a "sharp kill zone edge" (as simply cutting the blast radius works if you want to achieve smaller explosion).
I had plans to do it but I didn't do it because I get distracted by something else.

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?

Sure hope that after completing TFTD development team would consider integrating all those goodies into a main branch. Keep up the good work.
In theory can be done.

Integrating is pain in a**. Right now I facing lot of work to update with master branch, it's because Warboy move some code that I heavy altered in my branch.
I will need to redone most of my code or throw away Warboy changes.
Title: Re: [EXE] OpenXcom Extended
Post by: x60mmx on March 27, 2015, 08:40:07 am
Yankes, I downloaded Extended while toying with a re-balance mod since Open Xcom doesn't support many damage types having a blast, but I can not get it to work.  Here is an example of how I tried it.

      - STR_HEAVY_PLASMA_CLIP
    size: 0.3
    costSell: 9590
    weight: 3
    bigSprite: 25
    floorSprite: 33
    hitSound: 19
    hitAnimation: 46
    power: 115
    damageType: 5
    clipSize: 12
    battleType: 2
    recoveryPoints: 1
    FixRadius: 1
    RadiusEffectiveness: 1.0
Title: Re: [EXE] OpenXcom Extended
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.

      - STR_HEAVY_PLASMA_CLIP
    size: 0.3
    costSell: 9590
    weight: 3
    bigSprite: 25
    floorSprite: 33
    hitSound: 19
    hitAnimation: 46
    power: 115
    damageType: 5
    clipSize: 12
    battleType: 2
    recoveryPoints: 1
    FixRadius: 1
    RadiusEffectiveness: 1.0
You forget `damageAlter:`
Proper item should look like:
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.
Title: Re: [EXE] OpenXcom Extended
Post by: x60mmx on March 28, 2015, 07:58:00 am
Thanks for the help Yankes, and I am very grateful for Extended.  It will make so much possible!  :)

Is there any way to define at what range powerRangeReduction begins?  If not, any plans to?  Would be very helpful!
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 28, 2015, 10:53:48 am
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 28, 2015, 03:44:49 pm
Small update for linux fans.
I made experimental version for ubuntu. I hope it will work on other machines, at least its work on my VM :D
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 04, 2015, 10:33:59 am
You mean overkill damage? Or something else?
I can easy remove it (if you mean overkill), I only leave this because I very like that some damage types for default are more "explosive" than others.
Title: Re: [EXE] OpenXcom Extended
Post by: x60mmx on April 04, 2015, 10:06:51 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.

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.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on April 04, 2015, 10:36:52 pm
Yankes, I wanted to help you out, and since I can't code, I've fixed the readme file: removed spelling mistakes, fixed the grammar and made the text a bit clearer. The file is attached.

Issues:

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?
Title: Re: [EXE] OpenXcom Extended
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.

I think gamechanges like these should have a true/false flag so people can use what they wish and still be able to take advantage of Extended's possibilities.  With more mods made using Extended's capabilities, hopefully we could see those capabilities folded into OXC.
Question for other people who use my mod, do you don't have nothing against for reverting default behavior of overkill to default like in OXC  (overkill is when using hi damaging explosives & plasma damage, enemy "explode" without corpse left behind)? You can restore it after that by turning switch `IgnoreOverKill: false` in your weapon.

Yankes, I wanted to help you out, and since I can't code, I've fixed the readme file: removed spelling mistakes, fixed the grammar and made the text a bit clearer. The file is attached.

Issues:

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?

1 yes
2 this is what damage resistance in armor is used when you do damage form that weapon.
Polish: Angielski to trudna jezyka :D Ogolnie to ten stat sluzy do wybierania ktory rezist z armoru uzywamy podczas obliczania redukcji obrazen.
`damageType` ustawia to oraz tez inne staty ataku, moza powiedziec ze sluzy do ladowania wartosci domyslnych, ten stat zmienia to jedno tylko.

[ps]
btw thanks for fixes, I will apply them in next update.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 05, 2015, 02:46:58 am
https://en.wikipedia.org/wiki/100_%28number%29 ;P
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on April 05, 2015, 03:27:51 am
Why thank you, good sir. :)
Title: Re: [EXE] OpenXcom Extended
Post by: Hobbes on April 09, 2015, 01:37:25 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:

(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.
Title: Re: [EXE] OpenXcom Extended
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:

(https://www.ufopaedia.org/images/4/4c/XCom1_rank6_Commander.GIF) Commander
(https://www.ufopaedia.org/images/c/c3/XCom1_rank5_Colonel.GIF) Colonel
(https://www.ufopaedia.org/images/a/a6/XCom1_rank4_Captain.GIF) Major (insignia is the current one of Captain)
(https://www.openxcom.com/content/modimages/JCLYCDSQ040920150629.gif) Captain
(https://www.openxcom.com/content/modimages/NEISYHFN040920150629.gif) Lieutenant
(https://www.ufopaedia.org/images/4/47/XCom1_rank3_Sergeant.GIF) Sergeant
(https://www.openxcom.com/content/modimages/ZFCWCJEV040920150629.gif) Corporal
(https://www.ufopaedia.org/images/9/9b/XCom1_rank2_Squaddie.GIF) Squaddie
(https://www.ufopaedia.org/images/6/60/XCom1_rank1_Rookie.GIF) Rookie

This would require some change to the .EXE for the promotion requirements.
I once though about hijacking those to implement portraits for agents.
Title: Re: [EXE] OpenXcom Extended
Post by: jgatkinsn on April 09, 2015, 03:22:04 pm
Pretty sweet those ranks!
Title: Re: [EXE] OpenXcom Extended
Post by: Hobbes on April 09, 2015, 03:37:52 pm
I made those with some quick copy/paste.

I wish there was a better rank insignia for Commander. I never figured what the current one means, I assume it's a skull but it is weird looking.
Title: Re: [EXE] OpenXcom Extended
Post by: robin on April 09, 2015, 03:52:41 pm
The badges where likely made when the enemy was still unknown so they just made a weird-looking skull to represent an alien skull. If a skull is symbol of death, that would mean "alien death" :P
Title: Re: [EXE] OpenXcom Extended
Post by: Warboy1982 on April 09, 2015, 04:58:48 pm
50% skull, 50% mushroom cloud, 100% badass.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on April 09, 2015, 05:01:15 pm
Just to complete the derailment of this topic, the Commander's rank often strikes me a bit overly phallic.
Title: Re: [EXE] OpenXcom Extended
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..
Title: Re: [EXE] OpenXcom Extended
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...
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: jgatkinsn 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 :)
Title: Re: [EXE] OpenXcom Extended
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:

This would require some change to the .EXE for the promotion requirements.
Hard to say, I didn't touch this code to say if it will be hard or easy to do. Only one thing I recall that could be problematic is morale bonuses given by ranks.
I can put it on "far" todo list because right now I have some things planed.

BTW
Today or tomorrow I will publish new version, two main features will be physical training options (based on old WarBoy patch) and control over weapon turn restriction for aliens (contributed by redv).
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on April 09, 2015, 08:04:09 pm
Which Nightly will this new version be equivalent to?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 09, 2015, 08:16:24 pm
31.03, I postpone merging recent changes from master branch. Do you want newer version?
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on April 09, 2015, 08:44:55 pm
No, actually I hoped for precisely that one :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 09, 2015, 10:26:30 pm
Ok, new version is up.

changes:
Option for training rooms.
You can fully configure turn delay of alien weapon usage (global per weapon type/each weapon).
You can rename weapon slots in geoscape craft info (this is per craft).
Changed moment when current tu/energy bonus is calculated to weapon bonuses. Now is always: Spend Resources -> Calculate bonuses -> Apply damage
Previously when you do reaction shoot, game spend all resources for all shoots before firing any bullet. And normal shooting spend resources after firing bullet.


btw Solarius Scorch, when next time when you want fix my grammar mistaken, please edit this file:
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/Extended.txt
This is master file that I use to generate readme.txt, first post in this tread and Mod page description.
Merging manually readme.txt with that file is very easy to mess up and I did it already couple of times now.

[ps]
I forget mention one important change, I turn off default overkill damage because it was outstanding compare to normal OXC.
Title: Re: [EXE] OpenXcom Extended
Post by: robin on April 10, 2015, 01:06:05 am
Likely dumb question:
why there are two files, OpenXcomEx.zip, OpenXcomExElf.zip, for the same version (1.6) ?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 10, 2015, 06:36:42 pm
elf as name suggest is linux "exe" :D
Title: Re: [EXE] OpenXcom Extended
Post by: jgatkinsn on April 11, 2015, 07:03:26 am
So Yankes,

Have you thought about enhancing the civilian AI a bit in your version of OXC?

See thread where I apparently caused a bit of a ruckus: https://openxcom.org/forum/index.php/topic,3553.0.html (https://openxcom.org/forum/index.php/topic,3553.0.html)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 11, 2015, 12:45:01 pm
So Yankes,

Have you thought about enhancing the civilian AI a bit in your version of OXC?

See thread where I apparently caused a bit of a ruckus: https://openxcom.org/forum/index.php/topic,3553.0.html (https://openxcom.org/forum/index.php/topic,3553.0.html)
One thing that I once consider was give them alien AI (of course with changing who they consider as enemy) to allow them use weapons. Overall I made changes to AI but that was only small tweaks without changing overall logic. To made them smart would require lot more changes than that.
I don't know how to do it, I prefer doing change that I know how it should work before I start coding.
Last thing this don't align with goal of my branch that is increase modding capacity.


[branch progress]
Implemented new feature in my branch, now items/weapons can spend your HP, Morale and do stun damage when you use it. This required breaking change with old version because I removed old way of defining energy cost of use.
probably today or tomorrow will be new release.

[todo]
preprimed alien grenades
armor custom melee dodge and psi def
multiple inventory paperdolls
valid target specification for medkit & psiamp (special use attak)

[far todo]
range power reduction threshold
splash power reduction
more ranks
Title: Re: [EXE] OpenXcom Extended
Post by: jgatkinsn 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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on April 11, 2015, 11:21:47 pm
This might seem obvious, but new ranks would also require un-hardcoding rank requirements and bonuses... and here's an idea:

Most people would probably want for the new ranks to work as old Sergeant+ ranks (ie. just more officer ranks). How about allowing for an alternate option: a soldier can be given an officer rank, as normal (depending on the number of soldiers/officers), but he can also advance in non-officer rank (like, from squaddie to veteran squaddie, to elite squaddie), ex. based on the number kills*missions - this would allow to see the approx quality of a soldier at a first glance - frankly, I don't like "squaddies forever" syndrome which happens when there is no place for new officers anymore. Naturally, as soon as any officer's post opens, such veteran/elite squaddie can be promoted as normal. This would basically require breaking up the ranks into 2 categories: soldier ranks (based on experience) and officer ranks (based mostly on the total number of XCom soldiers).
Title: Re: [EXE] OpenXcom Extended
Post by: Warboy1982 on April 11, 2015, 11:24:16 pm
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.
Title: Re: [EXE] OpenXcom Extended
Post by: jgatkinsn 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 :)
Title: Re: [EXE] OpenXcom Extended
Post by: jgatkinsn 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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 12, 2015, 05:04:11 pm
New version ready
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on April 12, 2015, 05:45:03 pm
All good news.

Yankes, would it be possible to un-hardcode the race that defends Cydonia on the surface? (Normally Sectoids.)

I'd like to make that final mission a bit harder, with special defensive crew.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 12, 2015, 06:00:27 pm
un-hardcoding Cydonia is required by TFTD. I can made patch for normal OXC that will do it.
Title: Re: [EXE] OpenXcom Extended
Post by: Warboy1982 on April 13, 2015, 01:59:04 am
... it's not hard coded in the slightest, that was removed months ago (around the same time as mapscripts)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 13, 2015, 09:14:30 am
Done :D
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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).
Title: Re: [EXE] OpenXcom Extended
Post by: jgatkinsn on April 14, 2015, 02:34:30 am
So something like this: https://docs.google.com/spreadsheets/d/1rgHZaZYI7_WQ1-x_vTAmYcYCRpW2VFjPA3-Zfng3_bY/edit?usp=sharing (https://docs.google.com/spreadsheets/d/1rgHZaZYI7_WQ1-x_vTAmYcYCRpW2VFjPA3-Zfng3_bY/edit?usp=sharing)  ?

This is just a reference for a starting point for OXC ranks mapped to OXC Extended sub ranks.  I based it on U.S. Army, because it's what I know more.  I'm certainly not tied to the nationality for the ranks, since X-COM is a international military op.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on April 16, 2015, 05:46:11 pm
Yankes, while this is a bit bold, there's a feature that I would like to see in the game, and that desire grows every day.

We can now have any ships perform special missions (like Terror or Retaliation), but they all will deploy exactly the same crew, because STR_TERROR_MISSION and STR_BASE_DEFENSE aren't related to the ship that drops them. This pretty much kills the concept, since we can't have multiple crews for the job - the landing party is always the same.

Now, what I would like to propose is to ignore deployments like STR_TERROR_MISSION and STR_BASE_DEFENSE and use the same crew as the ship's. This would allow you much more freedom, for example to design several threat levels for alien missions. Besides, why would the landing party use different equipment than what they had on board? (Not that the difference was significant at any point.)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 16, 2015, 07:17:25 pm
Simply you want flag "ignoreMissionDeploy" in craft? :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 16, 2015, 11:09:47 pm
This will be probably easy to do. I will put it on my TODO list :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 19, 2015, 05:00:58 pm
New version is ready

Update to recent nightly.
I made Solarius Scorch request first because it had biggest `gameplay impact`/`lines of code` ratio :)

Now every ufo have two new properties:
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on April 19, 2015, 05:06:39 pm
Thank you, thank you, thank you!
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 19, 2015, 05:08:35 pm
You better should answer my dilemma with second stage missions ;P
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: SIMON on April 20, 2015, 11:21:15 pm
Just tried v1.8 of OPXCE on my current game involving "ufo redux" but the same thing happens when I had tried v1.7 of OPXCE. The game freezes during the hidden movement phase after my first turn and won't reach the start of my second turn. Any idea what's going on here? I was looking forward to trying the craft 4 weapon loadout, training room facility and my own mod acid bomb. Thanks in advance.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 20, 2015, 11:24:49 pm
If you switch to normal version every thing work fine? If yes then its my fault. What version of Redux you use?
Title: Re: [EXE] OpenXcom Extended
Post by: SIMON on April 20, 2015, 11:52:57 pm
redux version 0.5
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 21, 2015, 06:29:22 pm
I find source of bug, today I will probably make new version.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 21, 2015, 08:22:14 pm
Fixed version is ready, SIMON can you test that is every thing right? I could not test your save because of 20+ mods you have :D

[ps]
I updated to recent nightly too.
Title: Re: [EXE] OpenXcom Extended
Post by: SIMON on April 22, 2015, 12:28:06 am
I've given v1.8a a test run there on my current game and seems to run okay as I was able to do a sectoid/floater medium scout except for the base screens, they look pixelled, see attachments. Probably something very minor. Wud it be something to do with options I've enabled? One final point I wud like to know is when u get psionic training does that mean there wud be a choice of 4 buttons in the soldier screen ie: memorial, training, psionic and cancel. Still originally based off nightly of 2015-04-18 1150.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 22, 2015, 12:30:39 am
I updated to 21.04.2015 It have some big refactoring that could break palettes.
And about buttons, yes 4 buttons will appear.
Title: Re: [EXE] OpenXcom Extended
Post by: SIMON on April 22, 2015, 01:29:38 am
Just tested there with latest nightly (21 April) and everything seems grand but since I'm in the middle of doing the merc base atm, I'll start playing my current game fr OPXCE 1.8a and nightly 2015-04-21 after I hopefully complete the mission. Thanks again for all ur help, the soldier screen with 4 buttons looks excellent.
Title: Re: [EXE] OpenXcom Extended
Post by: SIMON on April 25, 2015, 02:27:59 am
Thoroughly enjoying this addition to my current game and I was wondering, as I have checked everywhere I can think of, what exactly are the increases that your troops get from the training room mod, is there somewhere I can read up on what a troop gets every month to what stat?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 25, 2015, 03:02:11 am
Change of stats is not tracked.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 26, 2015, 04:38:23 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 linear

Code: [Select]
        dodge
Front:  100
        100
Side:   75
        50
Back:   0

Or something completely different?

Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on April 26, 2015, 07:13:47 pm
Yeah, definitely should be penalized. Actually, it should only work against enemies the unit can see. (Except melee maybe.) (Actually, maybe it would be best to allow dodge an attack coming from outside the seen area, since we can always set it to 0 anyway.)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: yrizoud on April 27, 2015, 12:00:07 am
I'm not convinced by the mechanism, because it mostly works against the AI which will not take it into account as well as the player.
Title: Re: [EXE] OpenXcom Extended
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 linear

Code: [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?


Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on April 27, 2015, 11:23:52 pm
How does this "dodge mechanic" work?
Has a unit the chance to make a potential hit go missing instead?
From weapon hit chance you subtract dodge chance. Final value determine if hit was successful.
Logic is simple but probably enough for turn based strategy.
Title: Re: [EXE] OpenXcom Extended
Post by: Bloax on April 28, 2015, 01:00:03 am
A more complicated dodging system would have the unit walk a step away as the shot flies towards it, the direction of the step being the closest tile where there is no line of fire to the shooter if such exists - otherwise a random direction that is not parallel to the shot trajectory.

But that's just a little, difficult finesse.
Title: Re: [EXE] OpenXcom Extended
Post by: robin on April 29, 2015, 11:22:14 pm
made some tiles for the training facility.

get them here: https://openxcom.org/forum/index.php/topic,3350.msg43786.html#msg43786
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on May 10, 2015, 08:09:03 am
Got this result when tried your mod... face color values unchanged from before activating it (and it worked no problem before):

EDIT: Started to work when I've bumped up the spriteFaceColor number. Looks like, in Extended, you can only darken the shade, you cannot lighten it (as it was the case with my ruleset), while in normal OXCom it works both ways (darkening and lightening).
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on May 10, 2015, 10:58:00 am
Yankes, regarding soldier training on base, would it be possible to have two separate training facilities? Because I would like to have:
- Shooting Range: trains Reactions, Firing Acc, Throwing Acc
- Gym: trains TUs, Stamina, Strength, Melee
(Nothing trains Health and Bravery, you have to do battles for that.)
You can assign your soldiers to the Gym, to the Range, or the Psi Lab, but not more than one at a time.

I can imagine that the ruleset for each building has a list of stats that get upgraded monthly. And in the game, under "Soldiers" screen you get as many buttons as required with that ruleset, labelled "Psi-Lab", "Gym" and "Shooting Range". (Of course there are two separate behaviours with "Training at any time" enabled or not, so unfortunately the code would have to cover both.)
Title: Re: [EXE] OpenXcom Extended
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:
- Shooting Range: trains Reactions, Firing Acc, Throwing Acc
- Gym: trains TUs, Stamina, Strength, Melee
(Nothing trains Health and Bravery, you have to do battles for that.)
You can assign your soldiers to the Gym, to the Range, or the Psi Lab, but not more than one at a time.

I can imagine that the ruleset for each building has a list of stats that get upgraded monthly. And in the game, under "Soldiers" screen you get as many buttons as required with that ruleset, labelled "Psi-Lab", "Gym" and "Shooting Range". (Of course there are two separate behaviours with "Training at any time" enabled or not, so unfortunately the code would have to cover both.)
Biggest problem I have with this is UI. Right now is nearly enough place for two buttons and this would require another one. UI required by current training facilities was borderline of what I could add to my branch, because its add completely new screen. If I find way that don't require adding new screens or mess too much with UI, I could do it.


@Dioxine
I looking on this.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on May 10, 2015, 12:17:52 pm
The only workaround of this "gym problem" I see is:

1. Change "Psi Training" button into "Training" button. It would open up the training menu with as many buttons as required by the mod (one for each facility type); same with end of the month, multiple screen popup.
2. Rely on "r-click a facility" funcionality;

And I don't know how it works for now, but if trainings are mutually exclusive (a soldier can only train at a single facility at a time), this problem would be less pronounced.

Also this is a minor question... but maybe it should be possible to define "training caps" in the soldiers entry (where maxstats etc. are located), because some people (myself included) wouldn't like soldiers to be able to get to the very peak of their ability without ever smelling gunpowder, just with enough time in training. These would be defaulted to the same numbers as statCaps if not defined.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 10, 2015, 01:12:41 pm
The only workaround of this "gym problem" I see is:

1. Change "Psi Training" button into "Training" button. It would open up the training menu with as many buttons as required by the mod (one for each facility type); same with end of the month, multiple screen popup.
2. Rely on "r-click a facility" funcionality;
This was one way I could do it.

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.

Also this is a minor question... but maybe it should be possible to define "training caps" in the soldiers entry (where maxstats etc. are located), because some people (myself included) wouldn't like soldiers to be able to get to the very peak of their ability without ever smelling gunpowder, just with enough time in training. These would be defaulted to the same numbers as statCaps if not defined.
When I would add different training facilities then custom caps (or even starting requirements) is basic feature for this.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on May 10, 2015, 03:15:17 pm
I also thought a single button with a submenu would be best, but I don't know much about the UI and was hesitating to speak up.

Good call with the max stat improvement, too. (I think psi balance would also benefit from this limitation.)
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on May 10, 2015, 06:08:41 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).

- 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).
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
Post by: NuclearStudent on May 11, 2015, 03:51:41 am
If only the gym or the shooting range will improve reactions, it would be more intuitive if the shooting range improved reactions. Reactions are usually used to react while shooting and to duck when aliens shoot at you in game.

In my opinion having both improve reactions might be the best option.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on May 11, 2015, 04:39:32 am
Oh.. I did not realize I phrased my comment quite that way.. What I meant to say is that both facilities should do it. If a gym trains melee, then presumably it is a form of combat training which should increase reactions too. A shooting range can have a way to improve reactions as well, but it is more difficult to reproduce a combat situation.. Unless you have a paintball fight, or turn down the laser rifles to play laser tag :D

It is also for a balance reason. Reactions and accuracy are the two stats I value the most. Every thing else is secondary. With good reactions you survive better (shoot things when they show up and don't get shot up when showing up). With good firing accuracy you kill stuff. Training both at the firing range leaves the gym as a really secondary facility.

It might well be more productive the train reactions and firing at the range, then depend on fights to gain the TU/Str/Stam which will be easy to gain by shootings things. As opposed to training TU/Str/Stam in the gym and depend on fights to increase your firing and reactions (both hard to gain if you're not already good). Mods like Piratez which put an emphasis on melee would change that, but anything gun dominated like vanilla is dominated by reactions and firing.

On the hospital: You could have one to which you assign soldiers, with limited spots (since it would take alien tech and lots of money to supply it). Those assigned recover faster, the others recover at the vanilla rate. Really fancy hospitals with cloning tech might even allow you to bring back a soldier from the memorial!
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: pilot00 on May 11, 2015, 01:08:00 pm
If you put cloning tech into the fold it will be too much IMHO. I have played a lot of test runs with save scumming on and used the same batch of soldiers from the beggining ( in all X-COm, TFTD and piratez) reloading after each death. In the end you have a bunch of death machines that their only weakness is the psiweakness some might have. I do not recomend bringing soldiers back like that.

Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on May 11, 2015, 03:31:36 pm
@Solarius: That must be true.. Reactions is really important to me especially since it is so hard to get. You can train a high reaction rookie in everything else faster than you can train a sokdier that's good at everything to have good reactions. And reactions will save you, from being reacted to or by firing that warning shot that makes the chryssalid go back into hiding.

On cloning: It all depends on the cost and the timing. Not loosing any soldier allows them to train in each fight which makes them much better than a soldier who would die and be resurrected months later after cloning is invented and their cloning process completed.

There's a lot of tuning too. How long for xcom to make a full grown human? 6 months? How efficient is cloning? If you retrieve 50% of stats it's useless, so maybe.. 75%? I think it could be an interesting feature and take advantage of existing alien tech, but of course it needs tweaking.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on May 11, 2015, 05:49:51 pm
I just think necromancy is creepy. :P
Title: Re: [EXE] OpenXcom Extended
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.
*SNIP*
On the hospital: You could have one to which you assign soldiers, with limited spots (since it would take alien tech and lots of money to supply it). Those assigned recover faster, the others recover at the vanilla rate. Really fancy hospitals with cloning tech might even allow you to bring back a soldier from the memorial!
I would say that all of these things are good features. Not necessarily for vanilla XCOM, but they are good features to have available for not-entirely-XCOM things.
Title: Re: [EXE] OpenXcom Extended
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).

Title: Re: [EXE] OpenXcom Extended
Post by: the_third_curry on May 12, 2015, 03:47:56 am
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.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on May 12, 2015, 11:45:31 am
I just don't think the revival mechanics hold water. If X-Com had such tech, they'd indeed be producing cheap biorobots en masse (exactly like the aliens do), not clone their fallen comrades. Because this makes no sense whatsoever.

In fact, add a weapon flag that lets soldiers apply medikit-like items to themselves onto that.

That's also a good idea.

Speaking of medikits: I remember long ago that items were supposed to become exhaustible in OXCE, so a used medikit would be lost forever due to depletion just like ammo. (Even more pronounced in Piratez, where your healing items are alcoholic beverages.) Is it in the game, or not?
Title: Re: [EXE] OpenXcom Extended
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 :)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on May 12, 2015, 04:44:10 pm
Well writing code for this would be banal (all it takes is to retrieve a soldier from the Memorial - you can actually do it quite easily yourself by doctoring a save), but for me an important part of XCom is precisely the fact that the soldiers are mortal. You let them die, they're gone forever, all you can do is visit their graves.

One small improvement request I'd like: armor should be removed from soldiers that are killed & moved to the Memorial. Normally it makes no difference, but if it was a stat-modifying armor, the modifiers stay on a deceased soldier and I think it is inelegant (and in the case of revival/save doctoring, it is required - armor was destroyed, wasn't it, and if you have retrievable armor, it was retrieved, so the revived soldier cannot still have his own "copy" of the armor).
Title: Re: [EXE] OpenXcom Extended
Post by: Bloax on May 12, 2015, 06:40:11 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
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on May 12, 2015, 06:53:15 pm
Yeah, I'm not against in on principle - in some settings it would make sense, plus (I might be wrong) it's not that difficult to add.

Also a bugreport (or rather, inconsistency report):
Extended adds extra cost to weapon reloading (equal to the cost of moving an ammo article from where you have it stuck to an imaginary hand). HOWEVER, this does not work when you use the [R] key for reloading - the game uses base TU cost then.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 12, 2015, 07:14:05 pm
I don't think I will do any healing or resing in my OXCE build. It would require too much UI changes to work properly.
More probably I would add option to configure numbers of day off duty caused by wounds (configured by armor or maybe global too).

And for MediKit I already added option for self heal, it will be available in next build. Its very possible that I will releases it today.
Its depend on this if Dioxine stop throwing new bugs on my :D

Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on May 12, 2015, 08:36:56 pm
A minor one: Psi Amp doesn't display "out of range" message when the target is out of range (no buggy behaviour, just no message).

EDIT
Aaaand a major one. This below has happened when I used:
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... :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 12, 2015, 09:45:35 pm
how you do get this exactly? Using only this weapon and standard solders I can't reproduce this.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on May 12, 2015, 09:49:04 pm
Hmm, maybe it's the patient? She's susceptible to fire:
(nothing special about the Unit, 30 health, 60 bravery, no specabs or stuff like that)

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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 12, 2015, 10:15:00 pm
btw Psi-amp work fine for me. If you used debug do your solders relay see alien? Units still must obey LOS even if you see everything.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 13, 2015, 12:43:29 am
New version 2.0:
Update to recent nightly
Breaking change: Psi-Amp use now weapon dropoff and aimRange for attack chance.
Breaking change: Drop support for Regeneration stat in armor.
Inventory screens can now have up to 128 backgrounds.
Unit sprites recolors can now support up to 128 values.
Option for custom change of TU, HP, Energy, Morale or Stun after next turn based on unit stats.
New stat bonus based on stun level of unit.
Option for changing fuse type in granades and flare.
Option for pre-priming granades on map spawn.
Option for dodge chance based on direction of attack.
Oprion for bonus morale recovery when using medkit.
Option for self heal using medikit.


For now I used all primary ideas for changes. I have still some secondary things like custom ranks or custom training facilities.
But for now I open for request. Criteria are simple keep is simple and do not touch UI or Translations :>
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on May 13, 2015, 12:54:15 am
Ooooh, pick mine, pick mine!

I was disappointed that each craft weapon slot only supports one item type. I was expecting a list, so for example you could have one slot that only takes guns, another that takes either guns or radar enhancement, and a third one that takes everything. That's how I balanced everything in the FMP Extended project, but now I see it's not viable.

So, is it possible to have such lists for each craft weapon slot?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 13, 2015, 01:00:47 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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended 2.0
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:

Cannon: Cannon, Alloy Cannon, Gauss Cannon, Rail Cannon
Beam: Laser Cannon, Plasma Cannon
Light Rocket: Stingray, Stormlance
Heavy Rocket: Avalanche, Fusion Ball
Electronics: Radar Extension (radar range), Radar Res Processor (radar chance), Targeter (bonus accuracy, bonus damage)
Afterburners: Afterburners (bonus acceleration and speed)
Shield: Graviton Shield (20 armor)
Fuel Tank (bonus fuel)
Thrusters (bonus dodge +10%)

And here's the actual table for various planes:

(https://i.imgur.com/mmixVQv.png)

So some slots have a specified item type, some are unspecified, and some (most) have several specified types.
I see no reason to give an item several types, but well, it wouldn't change anything - but it's unnecessary, since you can control it from the slot end.
If this grow up. Here have a big big big game....
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Bloax on May 13, 2015, 06:50:47 am
Quick question: Is "the gym" just a feature in the base or do you actually have to make something to enable it?
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 13, 2015, 07:08:58 pm
Solarius Scorch in next version I will add this.

Bloax "the gym" currently work like psi lab. You need create building that have training slots.
Title: Re: [EXE] OpenXcom Extended 2.0
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.)
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 13, 2015, 08:35:14 pm
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.
Title: Re: [EXE] OpenXcom Extended
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.

Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 15, 2015, 07:50:34 pm
The possibilities of this modification are really awesome.

Since you asked for ideas/suggestions, here are some of my favorites.
1. Make it possible to attack terrain with melee weapons, for example walls. The best would be using the target cursor as for ranged attacks.
2. Allow for two different hit animations for melee weapons dependent on hit or miss. For the sound this is already possible.
3. For special abilities like 'explosion on death' or 'infectious chryssalid attack' define a chance that the special ability takes effect. For example tanks could have a 50% chance of exploding on death.
4. Holded items could modify stats/armor. For example a holded shield could give front armor bonus.
5. Building facilities could consume items from storage. For example building a Gravshield could be possible only if you spend a 'grav module' and 'elerium'.
6. Make it possible to add 32/24 bit images to ufopedia/inventory screen. I know it is not possible for battlescape/geoscape because of shading/lighting problem. However this is not the case for ufopedia/inventory. Even if only ufopedia would accept 32 bit images, modding would be much easier.


From this list only 4 and 6 don't fit my goals, first require too much code to work properly or it will be too limited to be worth doing it and second is too fundamental to be change by my branch. Rest of list look interesting and easy to do. At some point whey will be added to my branch.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Bloax on May 15, 2015, 10:09:53 pm
It would seem like you have broken the ability to use the blaster launcher, all it does is play the sound and eat up the time units - but not fire the actual missile.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 15, 2015, 11:29:49 pm
I will check out this.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 17, 2015, 03:12:25 pm
Bug fix version based on 2015-05-17 nightly is ready.
Fixed reload button cost.
Baster Luncher rocket don't disappear after first waypoint.
Stun regeneration work properly.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Firaa on May 17, 2015, 04:02:46 pm
Awesome project! It really has opened up a lot of potential.

One bug I have noticed is that accuracyMultiplier does not function at the moment. damageBonus is functioning correctly it seems, but accuracyMultiplier or throwMultiplier will not provide any bonus when given any input. A soldier with a firing accuracy of 70, Psi Skill of 50, and an accuracyMultiplier/throwMultiplier of psiSkill: 1.0 has 70 accuracy.

I've noticed this on 2.0, and it's happening on 2.0A.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 17, 2015, 04:21:45 pm
Code looks fine, test too. Can you show me your .rul? Maybe you made some error there.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Dioxine on May 17, 2015, 04:31:42 pm
accuracyMultiplier works correctly, I have tested it pretty extensively by now. Just notice there is an error in the mod description, it reads:

accuracyMultipler

instead of

accuracyMultiplier

(same goes for throwMultiplier etc). If you use the latter, the code works.

Also remember to set firing: 0.0 if you plan to base ranged weapon accuracy on another stat.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Firaa on May 17, 2015, 04:34:25 pm
This is the object I was testing accuracyMultiplier on. I've tried psiSkill, throwing, and flatHundred values, and again on throwMultiplier. I've tried this with both UFO Extender accuracy on and off.

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.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Dioxine on May 17, 2015, 04:35:38 pm
Yup, you have it spelled wrongly as Multipler
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 17, 2015, 05:13:19 pm
Sorry for confusion. I will fix readme in next version.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Warboy1982 on May 17, 2015, 08:22:36 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.
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 18, 2015, 09:48:04 pm
If I understand Warboy intend if I change code and his mod start behave differently I should stop publishing this mod. If I change code but mod still work as intended then every thing can stay as today. Did I understood this correctly, Warboy?
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Warboy1982 on May 19, 2015, 12:50:46 pm
you are, of course, free to do as you please with your build, including the code i gave you. i have no jurisdiction over that, and to suggest otherwise would be absurd. i'm simply saying if the functionality is changing, then the mod no longer represents what i intended, and as such i would like it taken down.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Dioxine on May 19, 2015, 05:55:44 pm
I'd suggest leaving Warboy's Apoc-style Training Room functionality intact, and making an alternate functionality apart from it when/if such a thing is needed, in part because I think many people would be interested in Apoc-style training rooms without any extras.
Before saying more on that issue I need to test it in the first place - I have no slightest idea how big the skill increases are, especially since XCom:UFO uses a vastly different timescale compared to Apoc (I wouldn't mind a link to the relevant code!) :)
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Warboy1982 on May 19, 2015, 07:11:08 pm
https://www.ufopaedia.org/index.php?title=Training_(Apocalypse)#Combat_Training (https://www.ufopaedia.org/index.php?title=Training_(Apocalypse)#Combat_Training)

https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/Soldier.cpp#L643 (https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/Soldier.cpp#L643)

the code is practically verbatim.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Dioxine on May 19, 2015, 07:37:56 pm
Thanks, it is really simple to understand. Any tweaking would probably entail:
1. possibility to customize the speed of training (circa +20 on first month all stats on a rookie might be just too much for longer campaign mods);
2. possibility to customize caps maybe (get statTrainingCaps, defaulted to statCaps if undefined) - if a modder wants the peak skills to be accessible only through combat experience. Still, the effectiveness of the training facility is really low once you're close to the maximum.
2. possibility to customize training facilities (any training facility has a list of stats that are trained there, defaulted to all if undefined)
Title: Re: [EXE] OpenXcom Extended 2.0
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)

https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/Soldier.cpp#L643 (https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/Soldier.cpp#L643)

the code is practically verbatim.
(Maybe you're already taking this into account in your code) Apocalypse cityscape is "organized" in weeks rather than months. Everything is (or seems, to me) synched to that shorter time-frame, compared to UFO: one day in Apoc is (or seems) a more significant (and, potentially, events plentiful) time span than a day in UFO.
So having training gain rate set the same as Apocalypse's, might be too much for UFO.

It should be tested. I understand though that this is not the priority right now.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: SDEDEN on May 20, 2015, 05:04:03 am
So I noticed the Training Facilities mod was updated in the OXCE mods pack. Uh, what was changed? Was it just the file structure?


Anyway, I'm no coder and I just play and mod XCOM for fun, but I've been using the Training Facilities with Extended 2.0 and it is quite potent. After about two months soldiers who have stayed in training that whole time are pushing high 50's to 60's strength. Another two months and they've got 60 health, 70 time units, 70/80 accuracy, and 70 strength. Melee and throwing accuracy are getting into 60/70's too. Pretty much everything but bravery and reactions is uber.

Now I've never played apocalypse, but I think some kind of cap on what the training facility does would be appropriate.

Like either providing a fixed, flat increase to each stat or raising all stats to a hard limit. Like you know, in the first option soldiers get 15 time units, 20 energy, 10 health, 10 reactions, 10 accuracy, ect...

Or cap health at 40, strength at 35, reactions at 50 (so that those really low types can be average), and such.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 20, 2015, 11:23:02 pm
Only file structure. Overall I have plans to add more control over stats of training facilities.
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 22, 2015, 01:43:18 am
New bug fix version with update to recent nightly.
Its fix reload bug and some UI issues with crafts.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Solarius Scorch on May 22, 2015, 02:04:08 pm
A thousand thanks, Yankes.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 23, 2015, 08:14:43 pm
New version 2.1:
Craft can now have up to 4 different wepon type per slot.
Oprion for overriding shape of alien base.
Option for setting chance of special effect of item.
Moving can trigger all close proxy not only one.
Corpse explosion now can have bonus based on unit stats.
Grenades now can explode at once without destroying each others.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Solarius Scorch on May 24, 2015, 07:17:49 pm
Splendid Yankes, great news again.

Now, I have another thing in mind that would be very handy for the Piratez mod (not so much for the vanilla X-Com, but maybe a bit). You see, it's a bit awkward to see 10 "enemies" being civilian passengers running around the ship, so you need to kill/stun them all to win.

The solution I propose is something I call "surrender mechanics". It is simple: whenever all remaining enemies are panicked, you win the battle automatically (just like when they're all mind-controlled).

---===---

And one more, completely unrelated, thing. In the Xcomutil, there was a "fix" for how the clips are recovered: for every clip there was a percentage chance of how likely it is to be recovered based on how much of it was depleted - so a full clip was always recovered, an empty clip was always recovered, a half-empty clip had 50% chance of being recovered, and a 10% full clip had 10% chance for being recovered, and so on. I really liked that system, since in the current one you hesitate whether to fire your special weapon (which you only have one of) because you know that even if you only fire one bullet, the entire clip will be wasted. Which is not very much fun. So I thought if we could, eh, have it the Xcomutil way. :)
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Arthanor on May 24, 2015, 07:45:08 pm
haha! That's an interesting idea. I just suggested reducing the size of some clips to alleviate the problem of "fire once, lose whole clip" in Piratez. That would be an alternative that's interesting. With OpenXCom counting bullets, it is much less of an issue for your main guns, but it is still really annoying for those guns you only carry 1-2 of and only fire 1-2 times.

Maybe it could be: Count bullets, get remainder of Bullets/Clipsize, give an additional clip back remainder/Clipsize*100% of the time? That's an easy step to add at the end of the current bullet counting instead of entirely replacing it. (One day I'll learn to code in C++! If only for these super easy things!)

That way if you fire 25% of the shots from two clips, you get one back for sure, with a 50% chance of the other. It is slightly different than 75% of keeping each (which gives you 56% of keeping both, 38% of keeping one, 6% of losing both). The results average up the same (average amount lost being either 0.5, or 0.38+2*0.6=0.5). It just makes the odds a bit more reliable (you know you keep one, you are more likely to lose one, and you won't lose two). Of course, if you only have one clip then it's exactly the same :P
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 24, 2015, 09:47:52 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.
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?
Title: Re: [EXE] OpenXcom Extended 2.0
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?
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Arthanor on May 24, 2015, 10:42:06 pm
I thought I had read that OpenXCom already counts bullets. I think it does something like this after the battle:
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.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 24, 2015, 10:47:43 pm
I mean different counting, you don't store clips but bullets. You use one bullet, you have 1 bullet less in base.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Arthanor on May 24, 2015, 10:56:31 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.

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.
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 25, 2015, 12:18:27 am
Right now its vague idea, I didn't check code to see what is possible and simplest to do.

Point is simple, outside battle item is 1 bullets. You load craft using e.g. 100 bullets. When battle begins all bullets are split to clips. If you lack bullets to fill clip, last one will be partial empty.
In battle you shoot 58 bullets. After battle left over bullets (in our case 42) are count up and return to base.

In that system only way to louse bullet is shoot it or drop clip behind.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Arthanor on May 25, 2015, 12:46:08 am
@pilot: As I described earlier, I am pretty sure that OpenXCom already has a system that does pretty much exactly what you describe, except it rounds everything down (so in your example, 2/3 of a clip is also 0 clip). It does it by counting bullets, but you never have to manage bullets.

The issue with your rounding, is if I have, say, a HMG and only ever fire 1/3 of bullets, then that mag lasts forever. You can't do systematic rounding as that creates bias. Either the OpenXCom way (rounding down) which loses you clips, or other ways (yours is ~fair but exploitable; always rounding up would be abusive). That's why I was suggesting bullet counting for clips, with the last # of bullets/clip size determining the odds of getting an extra clip. This way you get back the right number ±1, but it isn't biased.

@Yankes: I still think loading a craft with 512 bullets for your 6 guns is tedious, even if there would be no impact in battlescape. If you don't want half-empty clips, you have to be like: So I have 6 rifles, I want an extra clip per soldiers, each take 35 bullets. How many bullets is that? (12*35 = ..? *Pulls out calculator*) It's math I can do, or anyone past primary school can. But it's not math I would want to do routinely for a game (and I'd rather lose clips than do it ;)).

Maybe the game could track bullets, but only display full clips both in the base and in geoscape? So when you get in the craft equip/buy/sell screens, the game knows you have 600 bullets, so it tells you that you have 20 clips of 30 bullets. Coming back, you have 560 bullets, it tells you that you have 18 clips (18*30 = 540). Go on another mission and spend 35 bullets, you now have 525 bullets and it displays 17 clips. Buy 3 more clips, and 90 bullets and you have 615 bullets, displayed as 20 clips. That requires a lot of converting on the fly though.. so probably a lot of code change.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 25, 2015, 01:05:36 am
I could be possible. But you will loose information about not full clips. Each solution have some drawback.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: pilot00 on May 25, 2015, 01:45:49 am
All three of us actually say the same thing with different words and a small dissagreement on the % of the bullets gained or lost, so we are all correct :D
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Solarius Scorch on May 25, 2015, 02:55:44 am
And what about the surrender mechanic? Because it was kind of my main request of the two. :)
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Arthanor on May 25, 2015, 05:07:05 am
That one's a good idea and we all agree on it. Boring! :P

I'll have to take a dig at the debrieff state to implement something bullet wise. It seems like an easy project to start coding in c++ with since it's such a simple modification.
Title: Re: [EXE] OpenXcom Extended 2.0
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).
Title: Re: [EXE] OpenXcom Extended 2.0
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...
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Arthanor on May 25, 2015, 03:34:24 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.

@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.
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Arthanor on May 25, 2015, 04:12:12 pm
The issue is that it would list all of your gear that it recovered too:

Rocket Launcher: 2
Large Rockets: 2
Laser Pistols: 2
Laser Rifles: 8
Heavy Laser: 4
Plasma Pistol: 1
Plasma Pistol clip: 1
Plasma Rifle: 5
Plasma Rifle clip: 12
Heavy Plasma: 2
Heavy Plasma clip: 3
Alien Grenade: 5
MediKits: 8
Grenades: 4
Electro-flares: 18
Smoke grenades: 5
Mind Probe: 1
[...]

which quickly grows into a list that's so long it's useless. If you subtract what you brought, you would get:

Pistol clip: -2
Rifle clip: -4
Large rockets: -3

or something, which is interesting in its own right, to know what you need to replace, but you already get that message when it fails to refill the craft. And you don't really need to keep track of used equipment every mission provided it is there to be replenished. Unless there is an "owner" flag to items, which identifies if it was brought in by aliens or XCom.. But even then, if I bring 10 heavy plasma clips, spend 5 and recover 8 from the aliens, what should it display? Recovered 8 or recovered 3?

It's a good idea, but implementing it in a way that's informative but not cluttered is difficult.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Solarius Scorch on May 25, 2015, 04:19:02 pm
Good point. But I don't think we need an "owner" flag, as long as the game remembers what you brought and subtracts one list from the other - a bit like you described, just without displaying the negative values.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Arthanor on May 25, 2015, 04:22:03 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.
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Solarius Scorch on May 25, 2015, 08:12:48 pm
Adding a boolean "surrenders" line is fine too. Probably best, even though it'll be a pain to add it everywhere. :)
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: Yankes on May 27, 2015, 09:00:00 pm
New bugfix version (with recent nightly) ready.
I fixed two bug with berserker, first one that prevent unit form shooting and second that allow use of not researched weapons while berserkerking.
Title: Re: [EXE] OpenXcom Extended 2.0
Post by: pilot00 on May 28, 2015, 02:57:00 pm
I should probably start a campaign on this, now that my Piratez is not working. This mod is compatible with the FMP right?
Title: Re: [EXE] OpenXcom Extended 2.0
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.
Title: Re: [EXE] OpenXcom Extended 2.0
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... :(
Title: Re: [EXE] OpenXcom Extended 2.0
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.

So the experience should be the same as vanilla exe really.
When a versión compatible.

Enviado desde mi ECOO E04 3GB mediante Tapatalk

Title: Re: [EXE] OpenXcom Extended 2.0
Post by: new_civilian on June 04, 2015, 11:28:35 am
Just a HUGE thanks for this exe-mod! It is incredible what you made here, the training facilities and the ability to self-heal (medi-pack) and all the other things, this is heaven for us modders!  :) I really like the facilties-requirement-thing, it makes chosing different equipment pathes possible ingame, build a laser-lab for laser weapons and a gauss-lab for gauss etc... wow!

fwiw, the readme needs an update (the part about regen when use for items is still in it)
Title: Re: [EXE] OpenXcom Extended 2.0
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!

fwiw, the readme needs an update (the part about regen when use for items is still in it)
could you be more precise what line in readme need fixing?
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on June 10, 2015, 01:08:03 pm
What I meant is the fact that you dropped the support/feature of regenerating armor stats per turn, but the entries still appear in the armor section of your readme.  :)

Sorry for the late answer, was busy actually playing OpenXcom with your awesome Exe!  ;D
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 10, 2015, 07:38:18 pm
I drop support for old version. In place of it I added new one with different behavior (in "recovery" node). Hence I added warning about it.
Maybe I need rephrase it to be more clearly.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on June 11, 2015, 12:44:52 am
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.
Title: Re: [EXE] OpenXcom Extended
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  :)
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on June 11, 2015, 06:05:18 pm
Hey Yankes.  I've been having a discussion in the PirateZ extended thread about Spy Glasses.

This would be a nerfed mind probe giving Race and Rank only. 

However, I've come to realize that it wouldn't be possible unless the Mind Probe values could be externalized.  Meaning, a "probe" type item could give varying degrees of information according to how it would be defined in the ruleset.

Is that something that you would consider adding to your build?
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on June 11, 2015, 06:16:10 pm
Seems too much effort for (very) questionable benefit to me...

Maybe just display the race (and possibly rank, although I don't like that at all, also not in FMP... you shouldn't know what rank which individual is!) as text somewhere near the alien (resp. piratez human/hybrid) when holding a certain hotkey, or toggle.

Nah... after writing this, it's still a stupid idea... the sprites should really be enough to recognize the race... but that's just my opinion.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on June 11, 2015, 06:47:08 pm
The idea being exactly that: Help people learn what the sprites are to allow them to recignize the units later. It's a tool to help on a first playthrough. But I think it is possible to come with a LoS required and high enough TU mind probe where giving away stats isn't that big of a deal any ways. It's not like people heavily abuse mind probes in vanilla...

Another feature request for you Yankes:
1- The ability to define multiple inventory layouts (ie the "boxes" in which you put items). Currently you can modify that through ruleset, but there is still only one layout for all.
2- The ability to link different layouts to different armors. This way you could have a mule outfit with a huge backpack, a ninja outfit with barely any storage, a pirate outfit with a 3 tiles scabbard for a sword, etc.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 11, 2015, 08:11:40 pm
I probably give some love to mind probe because I didn't change it at all in my Extended version.

And for custom inventory, this would be problematic because lot of code depends on/use this (like AI, inventory templates, equipping units).
This would require more work that is worth.


I thinking about resurrecting my old branch: https://openxcom.org/forum/index.php/topic,2059.0.html
This could give couple of things:
1) Recolor of corpses and bigobj for unit.
2) Simple unit animations and fully customizable recoloring.
3) Large access to game logic by mods in long run.

Do you are interesting in that functionality? This would require some work but at least most of hardest thing are done in that branch.
But if nobody would use it, it would better if I spend my time on more useful things.
Title: Re: [EXE] OpenXcom Extended
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).
This would require more work that is worth.
If you keep the customization to player armor that would leave the AI alone. It's not like they really use the inventory much so tweaking it would be weird. As for templates and default equipment, save which inventory layout is used: if it's different, equip nothing. It's the player's responsability to re-equip a soldier if they change armors (which they probably would any ways, since armors tends to define roles).

Quote
I thinking about resurrecting my old branch: https://openxcom.org/forum/index.php/topic,2059.0.html
This could give couple of things:
1) Recolor of corpses and bigobj for unit.
2) Simple unit animations and fully customizable recoloring.
3) Large access to game logic by mods in long run.

Do you are interesting in that functionality? This would require some work but at least most of hardest thing are done in that branch.
But if nobody would use it, it would better if I spend my time on more useful things.
#1 and 2 are beyond me, #3 sounds like a very interesting thing, depending on what actually can be tweaked. It could potentially turn OpenXCom into a game engine instead of a game.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Extended Openxcom doubts.
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.
Title: Re: [EXE] OpenXcom Extended
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? ;)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on June 12, 2015, 06:54:09 pm
@Alinare
I have tested all these functions and they work flawlessly (well, extra fuel has trouble with non-standard fuel). Can you paste your code here? Else there is no telling what's wrong.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 12, 2015, 07:48:04 pm
I hope this means what I think it means.

And I think about the teleport device from UNIMOD.

What is UNIMOD? It's a big-ass mod for UFO: Extraterrestials. It added much, much stuff and made the game actually enjoyable, and ambitious.

What is a teleport device? It's a rare alien artifact added in UNIMOD that worked via throwing. When thrown, it disappeared on impact, and the user was teleported to the same location (with teleport in hand again). It was surprisingly non-cheaty, too.

Now, to implement it in Openxcom, one would have to write a script that would be then linked to a grenade, instead of doing damage. But it seems to be a bit too far-fetched for OXCE... Or am I wrong? ;)
Yes, that could be possible :> but probably not on first batch. It will take some time to expose all internals of OXC to script engine.

I think it can be done much simpler. Allow for custom-placement of fixed weapons? (built-in weapons). That way a modder can simply block some of the inventory space with blanks or whatever. He'd just make the biggest as the default and block off excess space everywhere else.
I think if we stick only to disabling then prober way to do it is add option to armor than using hacks. This have one good property that even if I f*** up game will still run fine only with some glitch. It would be possible to change this property without breaking saves.
Arthanor if you think that option in armor for disabling whole inventory part like backpack or belt then I can do it.


@alinare
Could you say exactly what you want to achieve? And as Dioxine said without your ruleset file I can't help you because I don't know what did wrong.
Overall to use properly Extended version you need understood how basic OpenXcom ruleset works without it is impossible even to understood Extended documentation.

Title: Openxcom extended doubt.
Post by: alinare on June 12, 2015, 08:07:30 pm
Hi:

Thank you for answering me so soon. I copied some of my mods listed. I do not get to apply these instructions, either, am I, who do not understand how they work. Here I refer you some examples. Sorry for the extension.

facilities:
  - Type: STR_NUCLEAR_DEFENSES
    provideBaseFunc:
      - STR_LIVING_ROOMS
    spriteShape: 3
    spriteFacility: 300
    buildCost: 500000
    Buildtime: 30
    monthlyCost: 50000
    personnel: 50
    workshops: 100
    defense: 800
    HitRatio: 60
    fireSound 5
    hitSound 10
    mapName: XBASS_21
ufopaedia:
  - Id: STR_NUCLEAR_DEFENSES
    type_id: 6
    section: STR_BASE_FACILITIES
    text: STR_NUCLEAR_DEFENSES_UFOPEDIA
    listOrder: 6990
extraStrings:
  - Type: en-US
    strings:
      STR_NUCLEAR_DEFENSES: "Nuclear Missile Defenses"
      STR_NUCLEAR_DEFENSES_UFOPEDIA: "Nuclear missiles, have maintained a tense peace During the recent and long Decades of the Cold War Between the two superpowers Nuclear deterrence prevented us the world again embroiled in another devastating world war, This Time, It Would Have Been With the nuclear.. exception of World War II, nuclear weapons Have never been tested in battle, and less against goals came from outer space, so do not know how They will behave. Each silo has a provision of ten missiles Renewed That will be as soon as will be fired. "
extraSprites:
  - Type: BASEBITS.PCK
    files:
      300: Resources / Mod / Facilities / Basebits / Nuclear_Defenses.png

Hello. This example, a nuclear installation defenses. So I thought understand the ProvideBaseFunc: it is a prerequisite for building the facility, but I can not apply.

Another example of a component:
items:
  - Type: Retropropulsor
    size: 0.1
    costSell: 10000
research:
  - Name: Retropropulsor
   requiresBaseFunc:
       - STR_QUANTUM_LABORATORY
    cost: 5000
    points: 50
    dependencies:
      - STR_ELERIUM_115
      - STR_PARTICLE_MICROACCELERATION
      - STR_ANTIMATTER_CONTAINMENT
      - STR_ALIEN_POWER_SYSTEMS
      - STR_ALIEN_GRAVITY_GENERATOR
      - STR_SECTOID_NAVIGATOR
      - STR_SECTOID_ENGINEER
      - STR_EXALT_MEDIC
      - STR_ALIEN_ALLOYS
      - Data Disc
      - Ragnite
      - Miniaturization
manufacture:
  - Name: Retropropulsor
     requiresBaseFunc:
      - STR_NUCLEAR_DEFENSES
    category: STR_EQUIPMENT
    requires:
      - Retropropulsor
    space: 20
    time: 150
    cost: 8000
    requiredItems:
      STR_ELERIUM_115 5
      Ragnite 12
      STR_ALIEN_ALLOYS 10
ufopaedia:
  - Id: Retropropulsor
    type_id 7
    section: STR_WEAPONS_AND_EQUIPMENT
    requires:
      - Retropropulsor
    image_id: UP220.SPK
    text: The retropulsor That is a drive unit runs on a mixture of ragnite and elerium-115, developing a huge new lift, capable of lifting the heaviest loads force.
    text_width: 143

If I have not misunderstood - in manufacturing-that line, what it does is, you have to build a deteminada easily, or produce something concrete, so that the object is made.
As for the weapons of the ships, another example:
craftWeapons:
  - Type: EXOCET
     stats:
        damageMax: 0
    sprite: 1
    sound: 5
    damage: 200
    range: 70
    accuracy: 95
    reloadCautious: 4
    reloadStandard 10
    reloadAggressive: 16
    ammoMax: 1
    rearmRate: 1
    launcher: EXOCET LAUNCHER
    clip: EXOCET MISSILES
    projectileType: 1
    projectileSpeed ​​5
items:
  - Type: EXOCET LAUNCHER
    size: 1
    costBuy: 70000
    costSell: 30000
    transferTime: 200
    weight: 3
    bigSprite: 2
  - Type: EXOCET MISSILES
    size: 0.1
    costBuy: 80000
    costSell: 40000
    transferTime: 74
    clipSize: 1
ufopaedia:
  - Id: EXOCET
    type_id: 2
    section: STR_XCOM_CRAFT_ARMAMENT
    image_id: UP087.SPK
    text: This is a weapon of the type "fire and forget" that Makes its way to the target near the crest of the waves, About 10 m. When approaching the target, it May drop to 3 m, in contrast, rise Rapidly to avoid the missile systems and precipitate on the target.
target.

In this case, the maximum damage of the missile, not add me to the other weapons of the ship. The same happens with the speed, and other statistics.
And, and I abused your patience, I ask another question, if possible:
armors:
  - Type: HEROIC KNIGHT ARMOR
    spritesheet: XCOM_B.PCK
    spriteInv: MAN_B
    corpseItem: STR_CORPSE_HEROIC KNIGHT ARMOR
    storeItem: HEROIC KNIGHT ARMOR
    weight: 25
    stats:
      stamina: 30
      reactions 10
      firing: 15
      bravery 10
      health: 10
      strength: 5
      firing accuracy: 6
    recovery:
      health: 12
    frontArmor: 120
    sideArmor: 90
    rearArmor: 90
    underarmor: 70
    damageModifier:
      - 1.0
      - 1.0
      - 0.0
      - 1.0
      - 1.0
      - 1.0
      - 1.0
      - 1.0
      - 0.6
      - 0.0
   
    loftempsSet: [3]
    recovery:
       health: 30

When I write, the option to recover 30 health every turn, openxcom disables the mod, and if I try to change, no effect.

I fail to understand that meaning, or function, have the letters in the brackets, or are lists of requirements:
requiresBaseFunc: [W, K]
provideBaseFunc [A, C]
I hope I explained well. I am Spanish, and my English, still leaves much to be desired. :)
Congratulations on this wonderful project. The other functions do not know as you call, they go perfectly. I understand for example, as will the tuaimed: cost and can lead, in time, health and other issues.

Greetings, and thanks again.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 12, 2015, 08:55:34 pm
"provideBaseFunc" - this is list of functionality that facility give to base, say for example "A". This can be any text.
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.
Title: Re: [EXE] OpenXcom Extended
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! :)
Title: Re: [EXE] OpenXcom Extended
Post by: Jo5hua on June 12, 2015, 09:56:00 pm
https://www.openxcom.com/mod/openxcom-extended

It is working now, sorry for the inconvenience. All is good now :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 12, 2015, 10:43:28 pm
thanks for fixing this :)
Title: Doubts resolved openxcom extended
Post by: alinare on June 13, 2015, 12:39:19 pm
Thank you so much. All works perfectly. Great job. :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 14, 2015, 09:08:52 pm
New version 2.2:
Option for custom sound and animation for miss attack and psi weapons.


S*** I hit message length limit in first post :/ I need think how best handle this now.
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on June 15, 2015, 11:49:52 am
Awesome!  8)

One minor thing though:

I could not get the recovery thing to work, the game exe complained about an operator working on a scalar or something.

My setup looked like this:

armors:
...
-STR_JustSomething_quick
   -recovery:
        health: 10.0
...

Sorry I do not have the full text I typed this from memory...  :P
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on June 15, 2015, 03:59:16 pm
You're missing one step here. You have specified the recovery rate, but not what you want to be recovered. The code should look like this:

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)
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on June 16, 2015, 12:39:35 pm
Oh, ok, now I see! Many thanks for the explanation.  :)



edit one day later: Ooooooh it works! Now my Universal Soldiers can automatically heal  ;D ;D

Again: Many thanks for this exe, it is just awesome!
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on June 29, 2015, 02:43:32 pm
Btw, now after seeing and liking the new training facilities: What about Med-Bays?  :)

Warboy released (some years ago) an OpenXcom version that had those (along with armed police-civilians). Just halving the required time to heal a unit would be awesome, it doesn't need to be an instantaneous recovery.

Apart from that: I just realized that your exe replaced the original openxcom exe releases for me. I no longer check the nightlies, only your mod.  :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 30, 2015, 07:23:12 pm
right now I don't have any plans to do medbays.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 02, 2015, 05:53:09 pm
Seems the retaliation against melee attacks got disabled in OXCom somewhere along the way (ie melee attacks do not provoke opportunity fire anymore). Is it posible to re-enable it?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 02, 2015, 06:41:13 pm
Probably yes, Warboy comment it out and I can simply revert it. But question is how manage it. Made it always enable/Global toggle/Per weapon toggle?
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 02, 2015, 07:46:11 pm
In my opinion it makes no sense when melee attacks can't be retaliated against, so I'd re-enable it across the board. I can't imagine anyone not wanting this... but then again, maybe someone would? It feels like a cheat.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on July 02, 2015, 09:05:38 pm
Why was it changed? I think I remember stun rods not triggering reactions in UFO (miss, miss, step aside and die was pretty common..) Did melee not trigger reaction in TftD either? Can't remember that one..

If it didn't in TftD, that would be a case of "staying true to the original" (however unrealistic), and maybe global toggle would be warranted. I can't really think of a situation where weapon toggle really makes sense.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 07, 2015, 01:43:29 am
New Version 2.3:
Option for defining percent of all action cost stats. Old use of `flatPrime` and `flatThrow` is deprecated.
Facilities can now require items to build.
Medikit can now be used without UI and can use `hitSound`.


Today version is sponsored by `sed` command scripts that allow remove multiple lines from text file.

Next version will probably have:
- melee reaction
- fixed weapon visible
- optional research items

After that I have possible plans:
- melee tile attack
- scripts
- flash lights of guns muzzle and explosions
- ammo for all items
- 1 bullet handling
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 07, 2015, 08:40:15 pm
I don't know if it's has been fixed already, using 2.2A. Double detonations.
- Sometimes, explosives detonate twice, causing double damage
- Would it be possible to define the number of detonations for an explosive (item-per-item basis)?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 07, 2015, 09:47:52 pm
Making "chain" detonation isn't hard, current game allow queue different explosions, repeating one is not hard.

But what about with that unintended "chain" explosions, can you reproduce it? Or in what circumstance it happened?
Remember that in my version one explosion can't stop another e.g. all proxy can explode when you step on two.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 08, 2015, 05:04:42 pm
Just throw any grenade & end turn, an unintended double detonation is almost certain to happen. I will send you a save.

EDIT: Actually sending a save is pointless, it happens all the time with Piratez. Might be an unexpected side effect of my grenades having 250 armor (ie. being indestructible by their own power).
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 08, 2015, 11:40:14 pm
Impossible, if explosion was needed to remove grenade then whole game would loop because second one could not do it either.
I mess up logics some were. Armor only expose this bug.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 10, 2015, 11:29:37 pm
Bug fix version is ready. I add recent commits form master branch, this mean I could add new bugs to it :D
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on July 12, 2015, 05:44:40 pm
The craft weapon screen is somehow buggy and weird now, it is off-center and the weapon names are not where they should be.

Talking about new bugs, the nightly also introduced an off-center mission abort screen text, whixch is now included in your exe. I reported the bug over the wiki.
And thanks for fixing the double explosion thing.

fwiw: melee reaction attacks already work, I saw that in a recent game, was VERY surprised.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 12, 2015, 08:12:59 pm
craft bug caused  by:
Bug fix version is ready. I add recent commits form master branch, this mean I could add new bugs to it :D
And for reaction, I didn't touch it jet. Probably another miss merge.
Title: Re: [EXE] OpenXcom Extended
Post by: robin on July 15, 2015, 12:34:31 am
I played around with this a bit (ver 2.3a + latest nightly).
Potentially useless feedback (because issues might be my fault):
 -- I'm getting only "OpenXcom 1.0" in the main menu screen;
 -- Shoot down a custom UFO and it spawned a never-ending wave of retaliation UFOs, even though the specific alien race had "retaliation: false";
 -- Terror UFOs keep roaming around but no terror site ever happens.**
Also I can't say if any of this is imputable to OXC, rather than Extended. Was just a quick lazy testing.

** this was my fault.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 15, 2015, 01:11:28 am
"retaliation: false" only work like basic version. To get no retaliation after shooting down ufo you should use "retaliationAggression: -100".
Title: Re: [EXE] OpenXcom Extended
Post by: robin on July 15, 2015, 07:19:13 pm
Another thing I noticed is that, when something explodes, the colors get "inverted" for a fraction of a second. Like in the image attached (the image is fake, I recreated the effect because I wasn't able to screenshot it, it's too brief).
Don't know if it is exclusive to the Extended version or not.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 15, 2015, 11:49:47 pm
This should be explosion flash form TFTD, probably another miss merge from my side. In weekend I will try fix all this bugs, and maybe add some new features.
Title: Re: [EXE] OpenXcom Extended
Post by: Searmay on July 18, 2015, 12:06:45 am
I assume this is a bug with Extended - it affects X-Piratez, but not the unmodified game:

Explosion hits are not attributed to the soldier that causes them for training and promotion. They do get credited with kills though. Tested with the Piratez black powder bomb ("direct fire" grenade), grenade launcher, and standard (prime + throw) grenade.

From some other comments it might affect incendiaries as well.

Version is whatever git cloned last weekend, so probably pretty current.
Title: Re: [EXE] OpenXcom Extended
Post by: wsmithjr on July 18, 2015, 08:16:34 pm
I apologize if this is a stupid question, but ...

I've read the posts at the beginning of the thread about Extended.  What I haven't quite figured out yet ... does Extended change the OXC game experience in and of itself, or does it only allow mods to do different things than vanilla?  So, if I install Extended and play it without any other mods, is it noticeably different from OXC?  Impressive list of changes in the first post but they seemed mostly to cater to mod authors.

Thanks for any help.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 18, 2015, 11:26:34 pm
Only minimal changes for normal users, 95% of it is for modders.
Title: Re: [EXE] OpenXcom Extended
Post by: robin on July 20, 2015, 10:43:02 am
I had a weird thing where both the medi-kits I equipped couldn't be used.
When clicking on "Use Medi-Kit" I was returned a red "STR_NO_USES_LEFT" (missing text string?) warning.

The unit was "on fire" (little flame burning on the unit) when I first got the message while trying to use the medi-kit.
I had used the medi-kits in the 2 previous missions but I really don't think I emptied them both (also normally an empty medi-kit should still work, just having its values at 0).

(Medkit is not the vanilla medkit, but it is 1:1 in ruleset terms, the difference is the main string, which is "STR_MEDIKIT2", all the rest is exactly the same as vanilla medikit).
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on July 20, 2015, 11:21:58 am
Happened to me, too, but i had forgotten to set the medikittype.  :)

Something I am not sure if it is a Extended exe or normal exe thing: Flame weapons no longer do any worthwhile damage. In some older exes my heatray weapons were really usable, right now everything incendiary/heat is useless, except if you add something like TOHEALTH 3.5 to the ammo, which makes them rather.... well, they are too strong and kill everything outright or they do no damage at all.... go figure.

Ah, one thing: Could explosion sounds be made customizable, too. Right now everything from tiny flame greneades over stunbombs to blaster launchers to modded nukes uses the same sound....  :-\
Title: Re: [EXE] OpenXcom Extended
Post by: robin on July 20, 2015, 11:40:32 am
Happened to me, too, but i had forgotten to set the medikittype.  :)

Something I am not sure if it is a Extended exe or normal exe thing: Flame weapons no longer do any worthwhile damage. In some older exes my heatray weapons were really usable, right now everything incendiary/heat is useless, except if you add something like TOHEALTH 3.5 to the ammo, which makes them rather.... well, they are too strong and kill everything outright or they do no damage at all.... go figure.

Ah, one thing: Could explosion sounds be made customizable, too. Right now everything from tiny flame greneades over stunbombs to blaster launchers to modded nukes uses the same sound....  :-\
I have the medkit type.


I'm using lots of incendiary weaponry and the damage output seems perfect; and I'm also finally seeing units lighting up in flames with consistent frequency. No issues here.


Well, there are actually two default explosion sounds, one for small explosions and one for big ones. The 'power' value should set which one to use. But of course, custom sounds would be welcome.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on July 20, 2015, 05:52:38 pm
Yes, the power of an explosion currently sets the sound that's being played. If I remember well, 85 is the first value at which you get the big explosion sound instead of the grenade pop.

I made a suggestion for customizable explosion sounds here (https://openxcom.org/forum/index.php/topic,3712.0.html) but nobody paid attention (or it's already in the works since TftD will have to have underwater explosions too?).

Maybe Yankes can make it happen for OXCE though.. It would be nice especially for flamethrower weapons, where the current explosion sounds don't really make sense.
Title: Re: [EXE] OpenXcom Extended
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.
When clicking on "Use Medi-Kit" I was returned a red "STR_NO_USES_LEFT" (missing text string?) warning.
I probably made error in "instant" medikits. This string should be shown only when you run out of charges in it, and medikit is "instant".

Happened to me, too, but i had forgotten to set the medikittype.  :)

Something I am not sure if it is a Extended exe or normal exe thing: Flame weapons no longer do any worthwhile damage. In some older exes my heatray weapons were really usable, right now everything incendiary/heat is useless, except if you add something like TOHEALTH 3.5 to the ammo, which makes them rather.... well, they are too strong and kill everything outright or they do no damage at all.... go figure.

Ah, one thing: Could explosion sounds be made customizable, too. Right now everything from tiny flame greneades over stunbombs to blaster launchers to modded nukes uses the same sound....  :-\
I do not touch damages types recently. Behavior should not change.

For big explosion sound, can be done. But first I need squash all bugs reported form last version. I will try finish it today or tomorrow.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: robin on July 20, 2015, 11:09:15 pm
MOOOAAAaar feedback.

1)
I noticed that the very first missile in air combat isn't drawn (shot from xcom crafts). This doesn't seem to happen in vanilla OXC.

2)
Got the attached error message.
For the following custom mission (all the ruleset custom stuff involved):

alienMissions:
  - type: STR_CORP_WAREHOUSE
    points: 0
    objective: 2
    spawnZone: 4
    [...cut...]

alienDeployments:
  - type: STR_CORP_WAREHOUSE_ASSAULT
    [ ...cut...]
    briefing:
      textOffset: -16
      background: BACK01.SCR
      showTarget: false
    markerName: STR_CORP_WAREHOUSE

alienRaces:
  - id: STR_NEUTEK
    retaliation: false
    # OXC Extended options:
    retaliationAggression: -100
    baseCustomDeploy: STR_CORP_WAREHOUSE_ASSAULT
    baseCustomMission: STR_CORP_WAREHOUSE_ASSAULT
Title: Re: [EXE] OpenXcom Extended
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.
When clicking on "Use Medi-Kit" I was returned a red "STR_NO_USES_LEFT" (missing text string?) warning.

The unit was "on fire" (little flame burning on the unit) when I first got the message while trying to use the medi-kit.
I had used the medi-kits in the 2 previous missions but I really don't think I emptied them both (also normally an empty medi-kit should still work, just having its values at 0).

(Medkit is not the vanilla medkit, but it is 1:1 in ruleset terms, the difference is the main string, which is "STR_MEDIKIT2", all the rest is exactly the same as vanilla medikit).
After checking code, error "STR_NO_USES_LEFT" can only appear if you use new instant medikit and you run out uses.
Something I am not sure if it is a Extended exe or normal exe thing: Flame weapons no longer do any worthwhile damage. In some older exes my heatray weapons were really usable, right now everything incendiary/heat is useless, except if you add something like TOHEALTH 3.5 to the ammo, which makes them rather.... well, they are too strong and kill everything outright or they do no damage at all.... go figure.
Did you use "RandomType"? this change how damage is roll.

MOOOAAAaar feedback.

1)
I noticed that the very first missile in air combat isn't drawn (shot from xcom crafts). This doesn't seem to happen in vanilla OXC.

2)
Got the attached error message.
For the following custom mission (all the ruleset custom stuff involved):

1) I can't reproduce it. Can you test it with F8 that will slow animations?
2) This is error with globe mission zones.

Another thing I noticed is that, when something explodes, the colors get "inverted" for a fraction of a second. Like in the image attached (the image is fake, I recreated the effect because I wasn't able to screenshot it, it's too brief).
Don't know if it is exclusive to the Extended version or not.
After looking close on big explosion I didn't find any bug. This you saw was indeed TFTD feature. It made all pixels bright for one frame.

I assume this is a bug with Extended - it affects X-Piratez, but not the unmodified game:

Explosion hits are not attributed to the soldier that causes them for training and promotion. They do get credited with kills though. Tested with the Piratez black powder bomb ("direct fire" grenade), grenade launcher, and standard (prime + throw) grenade.

From some other comments it might affect incendiaries as well.

Version is whatever git cloned last weekend, so probably pretty current.
fixed.

Tomorrow I will publish new version with all the fixes.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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 "**"):

  - type: STR_MEDI_KIT2
    size: 0.1
    costBuy: 3500 **
    costSell: 2625 **
    weight: 5
    bigSprite: 464 **
    floorSprite: 464 **
    handSprite: 464 **
    battleType: 6
    invWidth: 1
    invHeight: 2
    painKiller: 10
    heal: 10
    stimulant: 10
    woundRecovery: 1
    healthRecovery: 3
    stunRecovery: 4
    energyRecovery: 10
    tuUse: 10
    flatRate: true
See attached images. Taken with slow animations activated. Left launcher has 2 missiles, right has 1. As you can see, none of them gets drawn at all, you can't see anything flying towards the ufo.
So the issue actually is not that the first missile isn't drawn, but that during the very first seconds of air combat *nothing* (the cannon doesn't seem affected though, only missiles. duh, this is so strange) gets drawn.
-- edit: it also seems, to me, that the "invisible" missiles don't do any damage/never hit the ufo.
In the following days I'm going to switch back to vanilla OXC to test on there.
"RandomType": you misquote me, that text was for civilian.
And for medikit, I finally find bug in it, logic was right but I forget to init it in rule object and this get random value. In my test env I always get 0 that was correct value.

For missiles. Do you have same behavior with stock interceptors? It could be caused by rule sets. If I get ruleset that cause this I could easy fix it.
Title: Re: [EXE] OpenXcom Extended
Post by: begri on July 21, 2015, 07:26:39 pm
I need the simple files without the installer. Can you attach it somewhere?

I would like to try it on android.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 21, 2015, 07:51:38 pm
I need the simple files without the installer. Can you attach it somewhere?

I would like to try it on android.
Its pointless, I support only windows and linux builds. It even impossible to compile it for android because android port is based on custom branch of OXC.
Title: Re: [EXE] OpenXcom Extended
Post by: begri on July 21, 2015, 07:57:41 pm
Ok

If it have a mappa common and standard I would like to try it.

The nightly for win need just a copy paste to work. The language file in xcom1 mappa don't work on android I don't know why so for that I use the android build language file.

The files are just files...

But it looks like what the android version know that can accept.

I simple need the files...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 21, 2015, 09:03:14 pm
What "files"? Only file I give is one exe. To use it you need use nightly files.
Title: Re: [EXE] OpenXcom Extended
Post by: begri on July 21, 2015, 09:05:02 pm
Omg I had think it is an installer... Sad...
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 21, 2015, 10:45:03 pm
Ok new bug fix version ready. I hope I squish all bugs this time :)
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on July 22, 2015, 12:05:58 pm
Thanks a lot for your hard work, Yankes!

And i finally understood the flame damage calculation better and could make the heatray weapons work again. For those interested: Flame weapons do iirc 0-10 random damage for ~3 rounds when a unit is aflame. The ufopedia damage is only used for the area covered, it has no real meaning in terms of damage. So if you want to have a incendiary weapon have e.g. 40 REAL damage you can give it ANY damage value you want, it doesn't matter. However, you can adjust damage dealt by adjusting the TOHEALTH value (in Extended exe only of course) in my example this would mean TOHEALTH 4.0 which is dealt only once when hitting the target. Then you will get some random flame damage (0-10 iirc) for around 3 turns additionally. For a 130 damage flame weapon you would use 13.0 etc. However do not forget the additional random damage, so maybe use a slightly lower value.

And yes, Yankes, you had nothing to do with it, it's a vanilla exe thing.  :)

Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on July 22, 2015, 12:16:45 pm
I just discovered an interesting use for the requiresbuy function.

I wanted to declutter the research screen a bit, so I made an item with battletype 0 (geoscape only item like alloy and e-115) and gave it requiresbuy -LASERWEAPONS_Something so it would appear only after I could build laserweapons (just an example), then I added a research for this item (needitem:true is important) and made it unlock e.g. Gauss weaponry.

Result: I can now decide if I want to research Gauss weapons by "buying" a let's say RESEARCH CONTRACT GAUSS and only then will the researches appear in the research screen. If not wanted the research screen is emptier and cleaner.

It is even possible to use those "resources" (let's call the item GAUSS WEAPON KNOWLEDGE) in the manufacture list as a resource. That way the purchasable item remains interesting after the first research.

So far I "decluttered" Heatray, Terran plasma, Mass accelaerator and Railgun weaponry and boy does that research screen look tidy now or what!  :)

I gave the items a high listorder number (15000+) so they appear at the bottom of the list, this makes the purchase screen also look tidy. I recommend to use UPPERCASE names so the research items are easier to recognize from other items.

I hope this helps someone. Me for one, I am very content with the way it looks/works.

Good work Yankes, your work is really appreciated!  8)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 22, 2015, 01:47:55 pm
I had a similar idea (and even introduced it at some point), but for me, personally, a thing that you want to buy only once and then it does nothing beside cluttering the store would be unacceptable...

Also fire does 5-15 not 0-10 damage afaik. You don't need to use ToHealth either, just change RandomType to 1 for it to calculate initial damage like a normal weapon. You get a more "natural" blast damage propagation that way.

Also if you want items at the bottom of any list, omitting the listOrder altogether works best :)
Title: Re: [EXE] OpenXcom Extended
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 :>
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 23, 2015, 01:54:49 am
New version 2.4:
Option for defining bonus and damage type for melee in range weapons.
Option for big explosion sound for each items.
Option for showing fixed weapons on unit.

Today version is supported by low hanging fruit.
Title: Re: [EXE] OpenXcom Extended
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)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: SIMON on July 28, 2015, 12:54:54 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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: SIMON on July 28, 2015, 01:11:48 pm
Thanks for the tip, will do that now as there is no surprise at the end when you know the brain is upstairs in the t shaped room.
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on July 29, 2015, 04:37:18 pm
Yankes, there was a dogfight error in the original exe which got fixed, you might want to update to include that fix. Right now dogfights are rather one-sided (UFOs do not fire back correctly or only once).

I love the new explosion sound abilty!  :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: SIMON on August 01, 2015, 02:54:31 am
Just tried it again, using exe of extended v2.4 with everything else from nightly 2015-07-27-1005 but it crashes to desktop before landing site 13.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 01, 2015, 01:51:05 pm
But what mods was enabled? only HM 0.90?
Title: Re: [EXE] OpenXcom Extended
Post by: SIMON on August 01, 2015, 02:14:36 pm
No all, 35 in total(xcom1, 4 pre set, 27 user mods and the last 3 are for extended only-see attached) in the order shown. I've upgraded now to nightly 2015-07-31-1149 with hardmode v0.91 but haven't tried with extended or put on the last 3 mods until I heard back from yourself. Does landing site 13 load in for yourself?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 01, 2015, 05:29:46 pm
I find out that OXCE 2.4 is incompatible with nightly you are using (especially nightly past 28th).
Easy way of fixing it is use proper nightly that match extended version.
Today I will prepare new version for 27th nightly.

Newer nightly will be supported by next release. Because 28th have lot of breaking changes I will too do some breaks.
Motto for next release will be: "I heard you like scripts, so I put an script in your script that you can script while you scripting" :)

Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 02, 2015, 03:18:13 am
updated version compatible with 27-07-2015 is ready.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on August 03, 2015, 02:29:42 pm
Is the mod portal down again? I can't download 2.4A for some reason (suddenly a wild error appears).
Title: Re: [EXE] OpenXcom Extended
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: /
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on August 03, 2015, 02:45:51 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.

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)
Title: Re: [EXE] OpenXcom Extended
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).
Title: Re: [EXE] OpenXcom Extended
Post by: Ridаn on August 05, 2015, 04:41:26 pm
Is it possible to make projectiles of particular damage type or of some particular weapon to be unable to destroy terrain?
Its been bugging me for some time - dart rifles and stun guns introduced by mods can destroy fences and grass, and, if its stun damage is set high enough, even brick walls.

Its not anything major, really, but it might be a nice feature.
Someone even might use it to create a line of neutron-beam/microwave emitter/cryo-ray weapons using it.

Actually, now when I think of possibilities - is it possible to make weapons behave like psi-amp and ignore terrain altogether, or up to some particular value (to prevent sniping through UFO hull)? That can make for some scary-scary alien foes as well as some high end imbalanced weapon toys.
And, for sake of competition, it might be required to make non-stun damage type explosions ignore terrain (as in not-destroy, not bypass-altogether). Not sure if it should be tied to damage type or particlual weapon though.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on August 06, 2015, 01:50:27 pm
Yep, what Dioxine said^

I made some "neutron" bomb like grenades for my personal mod, skipping most armor and harming only health, no damage to items or tiles, pretty nice weapon for taking out armored units and can be balanced as well if you do not make them too strong.  :)
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on August 13, 2015, 05:58:57 am
hey yankes. do you support multiple soldier types?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 13, 2015, 09:40:45 pm
right now no.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on August 14, 2015, 08:06:37 pm
Is your version 2.4A based on borken Nightly or am I doing something wrong? Much of original texts ended up like this (texts added by the mod work normally).

Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on August 15, 2015, 06:58:48 am
on my system doesn't even run says something about can't read or missing folder
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on August 15, 2015, 09:08:36 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... :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 15, 2015, 11:47:20 am
Dioxine do you use correct nightly? To work properly it need be exactly version form that day because previous and next have breaking changes in rulesets.
It could be that. If you can't download correct ruleset you can grab it form github:
https://github.com/Yankes/OpenXcom/tree/OpenXcomExtended/bin
(This link will be valid until I start working on next release, after that you will need find this files using commit id from ruleset)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on August 15, 2015, 12:45:55 pm
I'm using the openxcom_git_master_2015_07_27_2340 as your mod page seems to suggest...?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 15, 2015, 01:44:49 pm
Strange, it should work. I can't download this zip because its too old to be show but using rulesets form the repo that should be exactly same work fine.
Another thing is that nether I or Warboy touch languages files or code to possible cause this bug.
Another question is original exe work same or different? Only thing I could suggest now is made clean install.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on August 15, 2015, 03:58:44 pm
Original exe works the same, with the same bug. No idea what's happening, I'll try it later.

Another issue, with the older build (early July I think, Extended ver. 2.3A) - seems that fixed weapons aren't recovered when a stunned unit comes back to life, at least with the old build I am using... Has this issue been fixed? Just asking because I don't track the bug fixes on daily basis.

EDIT:
the bug isn't appearing when the mod isn't enabled... but mod's strings are all fine...? I think it might be linked to the faux-master status of the mod... maybe I should put ALL of the language file into extraStrings? This would cure the ailment for sure, although it's a ton of work...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 15, 2015, 04:16:47 pm
I don't know, I only recall some Warboy commit about some "sticky" fixed weapons. Personally I didn't encounter this bug or fix it.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on August 15, 2015, 04:27:54 pm
All right, all I needed to do to properly upgrade to the new version Extended 2.4A was to put the en-US.yml file in mod's /language/ directory. :)

However, as of 27th July Nightly, the missing fixed weapons bug still persists.
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout 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.
Title: Re: [EXE] OpenXcom Extended
Post by: niculinux on August 18, 2015, 09:12:52 pm
Thank you for the mod, Yankes! Please, may you update the first post, since now i discovered it is avaiable also for linux, along with install istructions for that so?  Another useful tip would be to indicate mods that are compatible with it, hopefully ;)

EDIT: once next openxcom stable version will be relased, a dedicated ubuntu PPA for the mod may be also created, don't know...
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on August 18, 2015, 09:25:14 pm
I'm gonna use this for a special project. Been meaning to do this for a while. There are a bunch of things I'd like to be able to use.

When is TFTD modding supported for extended?
My problem was TFTD xcom2 folder can't be read. That's why was giving me can't read folder errors.  That's cause TFTD xcom2 is not supported yet in extended.


Also , if you think about it OpenXcom Extended features are probably what X-Com 3 would have had if they had made another game after TFTD.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 18, 2015, 11:25:30 pm
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.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on August 21, 2015, 10:41:47 am
Yankes, could you please consider changing how retaliation: false works, so that it prevented retaliation completely? This would improve behaviour of non-alien opponents (cultists, men in black etc.), as they would never travel on alien ships.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 21, 2015, 10:47:45 am
This already done by another property.
Title: Re: [EXE] OpenXcom Extended
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. :)
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on August 22, 2015, 02:53:40 am
yankes would it be possible to limit/restrict weapons based on skills?
Title: Re: [EXE] OpenXcom Extended
Post by: tollworkout on August 22, 2015, 02:59:17 am
also would it be possible to add stringstats for items ? like researched,  cost, damage type, power, aimedAcc, snapAcc, autoAcc, aimedTU, snapTU, autoTU, etc
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on September 07, 2015, 11:27:11 am
Hmm... it seems that the missionCustomDeploy doesn't use alert, briefing or marker name associated with the new deployment. Would it be possible to include this as well? Ideally only if the new deployment declares any of that (if not, the current behaviour should be enforced, ie. the custom deployment inherits the briefing of the basic deployment).
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on September 07, 2015, 08:27:44 pm
idea was that it only override alien weapon deployment. In theory it could be possible to "inherit" values but it probably will require manually handling all values. And that is thing I prefer avoid.

Another thing is why you need do it? Couldn't you create separate mission that will have different alert, briefing, marker?
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on September 07, 2015, 08:57:36 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 :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on September 13, 2015, 04:02:47 pm
From my experience with Piratez, and to a lesser degree also FMP, a big problem is that the AI cannot use weapons with limited range. This is rather sad, since you can't give the AI weapons like flamers or throwing knives and expect them to use them effectively.
I think overcoming this limitation would be fairly doable, though I don't know if it really is. The idea to implement would be:
1. Add one more check whenever an AI attempts to shoot a weapon. It checks if the weapon has limited range or not; if not (like most ranged weapons), then nothing special happens.
2. If the weapon has limited range, then the game checks if the target is in range. If yes, nothing special happens; if not, see point 3.
3. This actually requires some AI coding, but it's more or less the same as for aliens with melee weapons (which work). Essentially, the only difference is that instead of going straight to an adjacent square, the unit checks for distance after each step. If it is within range of the weapon now, it goes back to normal shooting; if not, it makes another step towards the target. Repeat until the unit is in range or it runs out of TUs.

Yankes, do you think it's relatively easy to do?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on September 13, 2015, 04:35:19 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".
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on September 15, 2015, 03:05:07 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...
Title: Re: [EXE] OpenXcom Extended
Post by: niculinux on September 15, 2015, 03:36:44 pm
Also, in openxcom extended, saved games are stored in the installation subfolder /user is that right?That is to say C:\openxcomExtended/user\ ?

Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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. :)
Title: Re: [EXE] OpenXcom Extended
Post by: stalks on September 20, 2015, 08:23:21 pm
Love your work, Yankes!

Any chance that you might be able to implement something like UFOExtenders "burst" and "full auto" firing modes?

What I mean is, they let you click on multiple points, and then would auto-fire ranging between those points.

In mods now you see a lot of weapons that fire very large numbers of shots in automatic mode (5 shots, even up to 20 shots!) but if you actually want to use these weapons to spray down an area you have to stick them on a rookie with bad aim and hope for the best, because someone with good aim will put all the rounds into the same spot.

If you could add the ability for a weapon to set two points for all the shots in auto mode will be distributed between, that would be great. (Basically, the first shot is aimed at the first point you click, the second 1/(N-1) of the way between the first and second points, the third 2/(N-1) between the first and second points, and so on until the last shot is aimed right at the second point)

That way we could actually use miniguns to shred cover in jungles, and try to kill several aliens that are grouped together with sustained fire.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on September 24, 2015, 08:40:17 am
Those firing modes would be very nice, but they certainly don't fall within this mod's objectives.

If someone was to program this, I guess it would use waypoints, a bit similar to the Blaster Launcher's. In the simplest model, the user would place two of them and the game would calculate a straight line between them, then place as many evenly distributed points along it as the number of bullets, then shoot one bullet at each point.
Title: Re: [EXE] OpenXcom Extended
Post by: stalks on September 25, 2015, 08:02:03 pm
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?
Title: Re: [EXE] OpenXcom Extended
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.

If someone was to program this, I guess it would use waypoints, a bit similar to the Blaster Launcher's. In the simplest model, the user would place two of them and the game would calculate a straight line between them, then place as many evenly distributed points along it as the number of bullets, then shoot one bullet at each point.
I degree with "certainly" :> This depend on scope of changes require to made it work. Even your example show possible solution that I could accept (because it reuse available things). Only question is it worth it?

Oh? Sorry, I didn't see a statement of objective for the mod, and from the features added I just got the impression that it was about adding modding options. I guess the part where it has interface behavior instead of just back-end behavior is what's out of scope?
1) increasing mod support
2) keep changes only to code (e.g. don't change original rulesets or add new files)
3) avoiding UI and Language changes (because if I want do it properly it will require violating point 2)
4) prefer changes with large "new game play mechanic" / "new code" ratio

In case of your request only thing that lack is point 4. But this could changed based how it will be implemented.
Right now my answer would be "probably not" / "maybe".
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on September 26, 2015, 08:32:52 pm
Ok, next catch up release will be today or tomorrow. I finished merging and I hope that I don't create new bugs :)
If I will have time I will try fix bugs that was reported from previous version.

Code is already published, I someone do not want wait then is possible to compile it himself.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on September 28, 2015, 02:03:56 am
New version ready. Primary change are from master.
I skip some recent commits but it should still work with current nightly.
In next week I plan add skipped commits and some bug fix.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 03, 2015, 12:39:56 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? :)
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 03, 2015, 04:29:21 pm
After finishing scripting I can add it.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 10, 2015, 01:12:28 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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 10, 2015, 03:47:40 am
The effect can find many uses, like illuminated sprites when the lights are off... Nice!
Title: Re: [EXE] OpenXcom Extended
Post by: TigerLord on October 10, 2015, 04:54:02 am
Where do I put the extender exe. please? Is there then a new way to use mods? I know there is instructions somewhere but ive been looking and cant find them.

Any help much appreciated, thanks:)
Title: Re: [EXE] OpenXcom Extended
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.

Any help much appreciated, thanks:)
Next to original exe. And to fully use extended version you need have mods that explicitly use functionality from it like Dioxine's X-Piratez.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 10, 2015, 01:26:52 pm
I think an option to have all the sprites fully illuminated regardless of the master light level would be totally cool :3 (you can shoot them normally, anyway... just can't tell who they are even if you soldiers see them... and more importantly, with NV mechanics, you want to turn the flashlights off, and then you can't see your own soldiers...)
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on October 10, 2015, 04:38:09 pm
Yeah! That looks awesome in the dark. Could we have enemies glow red, soldiers blue and civilians green when they are in the dark but spotted. That would be a great UI improvement.

Also, maybe a glowy sprite when something is spotted but not displayed because the ground tile isn't sighted? I hate those cases of "alien in sight but we'll only show you its shade when you put your cursor on it even though it is in broad daylight".
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 10, 2015, 05:48:24 pm
I'd rather prefer full color sprite than some blue, red or green approximations... we're not limited by the technology, are we? And even if we were, soldiers should be red and enemies blue, do'h! :)
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on October 10, 2015, 05:54:06 pm
But we already have a colour code established in OpenXCom - for the minimap! Aliens blue, civilians red, your guys yellow. If anything, we should stick with this, otherwise it'll be confusing as hell!
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on October 10, 2015, 06:23:38 pm
Ah.. yeah, Solarius wins the color coding design competition ;) Makes a lot more sense that way.. And I think it'd look cooler for night fights than actual full color sprites, just gives a night vision techy sweep feel.

That being said, full color sprites when the alien is seen but not the tile would be even better, yes. There is no reason not to display an alien that is in sight.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on October 10, 2015, 06:39:39 pm
Ah thanks. :)

Another idea is, how about, when the user turns off the lights, the entire screen goes monochrome? (The actual colour to be decided.) I mean it's displayed like on day vision, but in shades of just one colour.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on October 10, 2015, 06:52:12 pm
hum.. that could be cool too. Maybe monochrome very shaded green, with glow effect on units?
Title: Re: [EXE] OpenXcom Extended
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. :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 11, 2015, 01:22:47 am
Hold Your Horses :> Doing some global recoloring will be painful because you would need do it for all armors.
I don't have plans do custom recoloring for full screen because it will very easy hit performance limit.
Form good news I plan option for switch body parts of sprite using script. You will able change at last dying animation of unit based on look.
Title: Re: [EXE] OpenXcom Extended
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 :)
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on October 16, 2015, 06:29:54 pm
What about a way of blocking researches when doing another research. e.g. having to actually DECIDE about going for e.g RAILGUNS or going a different techtree. and NOT having both of them. This would make for real decisions and less cluttered manufacture/research screens.  :)
and what about the new soldiertypes of the latest nightly?  :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 16, 2015, 09:19:27 pm
Blocking research will be tricky, only way I see that can be do is block other research when you start new research project.

And for solders, right now I'm ignoring what happening in nightlys because I'm doing different things in my branch.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 16, 2015, 09:28:24 pm
Mutually exclusive research paths would be retarded in any sci-fi setting, the science doesn't work that way, but such a function could be really handy if someone wanted to make a sword & sorcery setting... While we're at it, random production results when? :3
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on October 16, 2015, 10:02:37 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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 16, 2015, 10:18:40 pm
I like that one, but to have something like that, you'd 'only' need to fix how getOneFree works... (I mean, repair the bug that causes all researches with 'getOneFree' be available w/o prerequisites unless blocked by requiresItem); but I think the bug can be circumvented (research Advanced Weaponry 'lookups' research str_trick_or_treat tech, which is blocked by 'requiresItem' and has 'getOneFree' on Laser Weapons and Gauss weapons).
But this are vagaries of science and the goodness of random, not the kind of moral choice civilian wrote about (don't get morals into my science! shoo! :)
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on October 16, 2015, 11:21:22 pm
Yeah, you're not sitting there as the commander, having to decide which of the two grant proposal to fund, but as you said, that's not really how science works. You don't forget one idea because you pursue another (unless you have a really crappy lab with little archival/note taking).

I guess you could have two scientists with big egos spearheading the two proposals, leading to one just leaving XCom if you don't pick his. Then by the time you complete one research tree, the weapons from the other one become available to buy because the scientists stormed out, got funding from an arms manufacturer and they are now producing it! That'd be cool :D (Yup, I'm a scientists and I think this can happen..!)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 17, 2015, 11:16:24 am
Speaking about moral choices... XCom morality should boil down to this:

(it's a bit like Bioware morality, but more ethical and much less veiled)
Title: Re: [EXE] OpenXcom Extended
Post by: robin on October 17, 2015, 03:39:03 pm
That's silly, it's obviously poisonous gas, so you can collect all the pristine alien tech left on the ground.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 17, 2015, 03:54:52 pm
Oh-ho, we have the first adept of the Lightside (Open Hand Style) here :)

(sorry for horrible OT :) )

also @Arthanor, I am relieved that the real science is still alive :)
Title: Re: [EXE] OpenXcom Extended
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 :)
Title: Re: [EXE] OpenXcom Extended
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!  :)
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on October 18, 2015, 07:09:45 pm
I think the main advantage of different soldier stats isn't overall quality differences, but different maximum stats and spreads of initial stats.

For example, in XCom: Human generalists and Hybrid psi-specialist that are kind of bad at other stuff for an Apocalypse mod?

For other things: Potentially different mutant strains for Piratez? Normal humans and Space Marines for a 40k mod? Elves, dwarfs, orcs and trolls in a Shadowrun or Fantasy XCom mod? It's a great feature, if someone is willing to put the extra amount of work to make it work (and I don't know how sprites and inventory images would work unless all soldier types look exactly the same..)
Title: Re: [EXE] OpenXcom Extended
Post by: new_civilian on October 19, 2015, 04:34:31 pm
I agree with what you say.

However, I discovered that my old personal xcom 1 mod (from september btw) no longer works with anything newer than version 2.4, so I will stick to that version from now on. So the new soldier types are irrelevant for me anyway.

Title: Re: [EXE] OpenXcom Extended
Post by: moriarty on October 23, 2015, 05:37:06 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?
Title: Re: [EXE] OpenXcom Extended
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!
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 23, 2015, 08:44:24 pm
This will be hard, because it will require handling all special cases of each type at once. e.g. when you use items then you need update all labs and factories because you could lost some "work hands".
Another problem is how it will fallback to basic exe, it could require breaking compatibility nightly (right now is still possible to load save without crash).
Title: Re: [EXE] OpenXcom Extended
Post by: moriarty on October 24, 2015, 10:35:54 pm
I see. too bad, actually...
what about the possibility to acquire engineers and scientists from other sources, like getting them after successfully completing certain missions?
would that be possible?
perhaps even tied to stuff like survival of certain civilians on the battlescape?

...you know, the old "retrieve the specialist" mission (or, in the case of XPiratez, "capture the specialist")...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 25, 2015, 12:33:39 am
This should be doable.  I could even say that partially I have it in plans because when I add full script support then adding this after mission will be trivial.
Title: Re: [EXE] OpenXcom Extended
Post by: KingMob4313 on October 25, 2015, 02:47:29 am
How about flagging soldiers as 'researchers' and when they are taken out on field missions, when they return, they generate research points?

Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 25, 2015, 03:31:01 pm
If you only want that after successful mission one of research topic will grain progress then it will be at some point possible.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 29, 2015, 04:21:56 pm
Hey,
Where can I download the required Nightly (19 sept. for 2.5 OXCE)? I know it's on the Git Hub, but I'm kinda lazy and incompetent regarding that system... Question void if you're planning a new release soon, Yankes :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 29, 2015, 08:42:38 pm
No new version soon, I'm now around 1/3 done and I need couple of full working days to finish. This mean week or more to do it.

In attachment there is data for version 2.5
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 07, 2015, 12:54:04 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.
Title: Re: [EXE] OpenXcom Extended
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'...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 07, 2015, 04:50:41 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.
I have some thing like that in my far plans. Most objects in game will have customizable properties not used by game:

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.
Title: Re: [EXE] OpenXcom Extended
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!
Title: Re: [EXE] OpenXcom Extended
Post by: cowboy on November 17, 2015, 04:43:47 am
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!
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 17, 2015, 02:40:07 pm
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 :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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. 
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 20, 2015, 09:48:55 pm
Hmm, add ability to gunMelee and (maybe, if not too difficult) to shoot & be primed to all Battletypes? :)
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on November 20, 2015, 09:53:24 pm
Rookie #1: Incoming! OH MY GOD IT'S A CHRYSSALID!! *runs away screaming*
Rookie #2: *panics and prime whatever he had in his hands, drops it and run*
*Chryssalid steps on a primed medkit, gets exposed to a weird cocktail of all kind of drugs, overdoses and falls in a coma*
Commander: Quartermaster! We need more medkits to take out those aliens. Forget about the grenades, they weren't enough.
Title: Re: [EXE] OpenXcom Extended
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.

Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 21, 2015, 01:15:15 am
Shooting is not important that much, better save shared functionality between objects. But melee'ing with any kind of object, or making it explode, would be awesome. The third - shooting - function is not needed that much, I doubt there would be much sense in shooting Medkits (and it would also raise problems if medkids were made to accept clips :) ) Firestorm-wand can be done already with no trouble, it's just a battleType 1 with a lot of extra code :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 21, 2015, 01:50:16 am
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 21, 2015, 02:13:28 am
bug fix version 2.5a ready
- consistent craft stats
- stun unit items
- exposion radius based on stats
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 21, 2015, 01:40:10 pm
Yes, and how melee don't work? What happens exactly?
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 21, 2015, 02:01:58 pm
The Psi-Amp misses all the time (30 consecutive misses with hit chance = 71%), playing 'failed psi attack' sound while doing that.

The meele code:

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?
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 21, 2015, 05:16:47 pm
Another problem found:

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)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 21, 2015, 05:57:32 pm
Sorry, readme f*** up. `meleeDamage` -> `meleeBonus`.
And for psi-amp, I will look on this in code. Probably some special handling of psi attack override melee hits.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 21, 2015, 06:51:33 pm
Thank you, now it works :)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 21, 2015, 10:31:55 pm
Hmm, melee reactions now seem to crash the game (ver. 2.5). Could you look into their code? Does 2.5A run on the same nightly? Might be that specific's Nightly's bug...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 22, 2015, 01:55:13 am
2.5a use exactly same nightly as 2.5 only difference is bug fix.
Do you have savegame? it would speed up reproducing thins bug on my side.

[ps]
test with basic xcom don't show crash when enemy react with melee. I need more information to fix it.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 22, 2015, 02:10:06 pm
The crash save. Needs piratez 0.96, but you have to install 'em on OXCE 2.5 (the DL package contains 2.4A); just wait a couple of turns, an enemy should go through the door, prompting the crash. Such crashes never happened before...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 22, 2015, 02:33:17 pm
thaks, I will look on this.

[ps]

It looks like problem is with walking sound rather than reaction. It gets value 999 and crash when you see movements of that unit. You can test it by using debug mode and it will crash turn earlier. I will check if its some problems with loading ruleset.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 22, 2015, 05:15:15 pm
Hmm, this unit uses default walking sound. This makes sense, since there was a crash earlier when a power-armor unit just walked into gals' view... But why suddenly the default walking sound would be bugged? Map settings?


EDIT: the problem is caused by moveSound: -1 in armor's entry... While movesounds have been moved from armors to units, or at least doubled. DAMMIT I HATE SUCH CHANGES. Especially since the 'default' -1 just moves it to 999, breaking the game... :/ What's the default number which causes an unit to use normal terrain-dependant walking sounds?
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 22, 2015, 06:10:14 pm
Allright, alerts off, seems that removing all movesound:-1 eliminates the bug... now only for a gruelling work of upturning the whole ruleset, to eliminate STR_FLOATER and STR_SNAKEMAN, and turning them to STR_GUILD and STR_CHURCH...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 22, 2015, 11:34:35 pm
Problem is that "-1" should be correctly handled by game as "no sound". I will look on nightly and my branch why this is miss handled.
I didn't jet have time to work with this but most of values from ruleset get mod offset even if it should reference basic sounds.
Title: Re: [EXE] OpenXcom Extended
Post by: Imeryak on November 24, 2015, 07:09:14 am
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?
Title: Re: OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 27, 2015, 05:36:57 pm
Modsite link for the 2.5A is broken again... can you update your Mediafire backups, as they end on ver. 2.4?
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 27, 2015, 11:55:33 pm
new bug fix version ready. Two things was fixed. Handling of melee in psi-amp and loading unit sounds in ruleset.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 28, 2015, 02:23:22 am
Cool! Now I can make the true magic staff experience, and loading sounds also sound like a great addition to make the game more flavorous :) Is this new version still called 2.5a, since I can't find any newer in the downloads?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 28, 2015, 09:49:55 am
its on mod portal, now I check links are correct :)
Title: Re: [EXE] OpenXcom Extended
Post by: niculinux on November 28, 2015, 08:41:48 pm
Dear Yankes, just downloaded the linux version 2.5b replacing the old 2.4a but i find the statstrings are on by default, but i did not activate them, see screenshots attached. So how i may turn them off?

Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 29, 2015, 12:32:20 am
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?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 29, 2015, 01:34:04 pm
If you use redux is possible that it give this stat strings.
And another thing xpiratez aren't crashy with 2.5 but incompatible. You need have correct version Extended and xpiratez to work properly.
If I recall correctly lastest version is still on 2.4 but next one will be based on 2.5
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 30, 2015, 01:13:58 am
There are big differences, since 2.5 is based on September Nightly and 2.4 on May (I think). So it's a wonder you were even able to launch the game at all.
Title: Re: [EXE] OpenXcom Extended
Post by: The Reaver of Darkness on November 30, 2015, 11:23:06 am
Can I use this to change the base layout to 8x8?


I also want to make 2x4 tanks. It can theoretically be done, they just need to check a few squares next to them for passability when turning.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 30, 2015, 07:38:46 pm
Can I use this to change the base layout to 8x8?


I also want to make 2x4 tanks. It can theoretically be done, they just need to check a few squares next to them for passability when turning.
No and No. Base don't have enough room to add new rooms. Adding scrolling would be overkill. And for tanks, this would need modification in lot of different places. Every part of battlescape would need changes only to support this.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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%?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 01, 2015, 07:55:30 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.
Most of my answer could be Dioxine post. One point about "battlescape needs changing", I except that to do it right it would require rewrite half or battlescape code to made 4x2 units works. AI, Path Finding, Map and Unit rendering. And is big possibility that it will end up as big mess (3x3 would be more possible).
And finally one things that prevent it even if I could made it. This will break backward compatibility with basic version. its still should be possible to load extended save in normal exe, of course without any new functionality form extended version.
Title: Re: [EXE] OpenXcom Extended
Post by: The Reaver of Darkness on December 02, 2015, 07:26:49 am
What if it was counted as a 2x2 for purposes of placement, movement, and hit restrictions, but reserved a couple spots in front of and behind it on the transport, and drew a larger sprite which covers up whatever is on the squares in front of or behind it? It would have some graphical glitches but you could avoid that if you wanted by not driving it next to walls.

Well I'm okay without these, they're not really worth buying anyway. At this point I'm just curious to find some way to do it. I'd really like to see an 8x8 base layout though. I wasn't aware that the base screen can't have its resolution changed.


Is there some way to make an aircraft storage facility that can hold multiple aircraft which are not fueled, and make it so they can be transferred to hangars?
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on December 02, 2015, 06:25:28 pm
Reaver, the base thing has already sort of been implemented by Fenyő here (https://openxcom.org/forum/index.php/topic,2559.msg25857.html#msg25857). I really liked the option too, but it was... not added to the main branch.

You can read more about it in that thread (the video is a good demo of the features), and Fenyő's branch is still up on github (https://github.com/fenyo1/OpenXcom/branches) so one could merge it into their game. Base handling shouldn't interact with much other code, except maybe Yankes' base facility requirements code. I haven't tried to merge it, but eventually will I think. Unless Yankes is willing to merge it into OXCE and literally extend XCom :D
Title: Re: [EXE] OpenXcom Extended
Post by: robin on December 03, 2015, 11:59:36 am
the customization of the explosion animation is an extended feature or is it available on vanilla oxc too?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 03, 2015, 07:02:35 pm
vanilla, I only add custom sound.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on December 04, 2015, 01:26:36 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?)
Title: Re: [EXE] OpenXcom Extended
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)
Title: Re: [EXE] OpenXcom Extended
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).
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on December 04, 2015, 08:04:29 pm
Another minor request:

Do you think you could add a lineto UFOPaedia articles for meee weapons? In the same way it shows:

XShot  Acc  TUs

it would be really nice to have:

Melee  Acc TUs


Would save Dioxine writing all that in the UFOPaedia description.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 04, 2015, 08:20:21 pm
Another minor request:

Do you think you could add a lineto UFOPaedia articles for meee weapons? In the same way it shows:

XShot  Acc  TUs

it would be really nice to have:

Melee  Acc TUs


Would save Dioxine writing all that in the UFOPaedia description.
It will be hard because not enough space for 4th line. Without some sacrifices it is probably impossible.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on December 04, 2015, 08:47:52 pm
hum.. good point. What about:

If all 3 shots are defined, don't show melee option even if it is there. The weapon is obviously a gun and the modder can add melee info if they want.

If not all 3 shots are defined, you have space, melee info is shown.

That would allow better presentation of the melee info for all purely melee weapons, and most of the hybrid weapons.

Or if not that, then maybe only for weapons that don't have any shot? Currently, only the power of the weapon is shown, and everything else has to be put in the description. Having one line for the stats of melee weapon would improve things to some extent, and make the ufopaedia more uniform.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 04, 2015, 09:50:06 pm
Another possible solution is change font to smaller one or simply allow modder to alter overall layout of page (but not adding new one).
Overall I bit ignored ufopedie, none of my changes are reflected in it.
At some point I should spend some time improving it, but right now I have other things to do.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on December 04, 2015, 10:41:15 pm
I don't care either way. And what Arthanor proposes might be actually more confusing than helpful - a normal human expects to find one info in one place, not be dazed by information that constantly jumbles around the whole page.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on December 04, 2015, 10:52:17 pm
Seemed more consistent to me (all the accuracy and TU costs in the same place, instead of melee ones tucked away in the description). That was actually the point of the suggestion. Although granted the "only show if there's place" idea is bit more confusing.

Oh well, there are indeed more important things that could be worked on. Just wanted it to be somewhere in the ToDo list ;) (or quickly done, before the space issue was pointed out).
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on December 10, 2015, 12:29:27 am
Yankes, it may be bold of me to ask, but what is this scripting you are working on? Because it comes up pretty often from you, like "I'll add this when I get the scripting done", or "Yeah that's interesting, but right now I'm doing scripting". So I naturally got curious about this scripting thing. Is it related to the vanilla mission scripting (or even the same thing), or did you mean something else entirely?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 10, 2015, 01:17:28 am
"Turing complete" scripting e.g. you will can add any logic you want to game. Instead of adding new properties or special cases in code you could add new things using only ruleset. like "When your commander die you lose game", "Spawn unit after grenade explosion" or mix both "lose game after ANY grenade explosion" (some part of game could be reimplemented using script to allow change it by modders).

Right now I stuck on trying figure out how made it scalable, because its work from long time but would be hard to do lot of things I plan in current state.

Of course I do it in Hard way because I code all my self :). Simpler solution would be drop all my code and add some ready solution for some library.
But that would not be so fun :)
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on December 10, 2015, 01:26:03 am
OK, I get it, hat's off, man. This is big.

So, how is it going? Can we put you under pressure now? :)
Title: Re: [EXE] OpenXcom Extended
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 ==========
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on December 11, 2015, 06:29:57 pm
Hi Meridian,

I've used commit 808f8 from Nov. 27th to compile and then run X-Piratez without issues. Did you try to add something else in there? That's usually where things go wrong..

I have a code version with "manufacturing profit/cost info" and "statistical bullet conservation" added, which works fine. Depending on which feature you are looking for, I could look into making a "custom OXCE code" and publish that on github.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 11, 2015, 06:48:02 pm
808f86 is lasted released version. In OpenXcomExtended branch is working copy of next version.
"OpenXcom version: Nightly 2015-09-15" mean what base nightly is compatible with.

For compile errors, some ".cpp" files aren't added to project files. Chack if you have added "AllocateTrainingState.cpp", "RuleDamageType.cpp" and "RuleStatBonus.cpp".
Title: Re: [EXE] OpenXcom Extended
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... :(
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 12, 2015, 01:55:53 am
could you show where in OpenXcom code error is generated? type_traits is standard library and without more information I can't find cause.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on December 12, 2015, 12:23:05 pm
Here's the entire console output:

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 ==========
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 12, 2015, 03:18:00 pm
I push on master possible fix.
But I have bad news, next release (3.0 with scripts) will be incompatible with vs2010 because I move to C++11 with code base.
This will require to upgrading to vs2015 community edition.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on December 12, 2015, 11:28:16 pm
It works, thanks!
After updating I also had to add one more file (TrainingState.h/cpp) and then it was OK.
Title: Re: [EXE] OpenXcom Extended
Post by: The Reaver of Darkness on December 13, 2015, 12:25:15 pm
request: would it be possible to make damaging shots deal 10% of their before armor damage to armor, instead of 10% of their after armor damage?

Example:

In XCom...
Shot deals 80 damage, target has 50 armor, target takes 30 damage and target's armor takes 3 damage.
Shot deals 50 damage, target has 50 armor, target takes no damage and target's armor takes no damage.



What I want...
Shot deals 80 damage, target has 50 armor, target takes 30 damage and target's armor takes 8 damage.
Shot deals 50 damage, target has 50 armor, target takes no damage but target's armor takes 5 damage.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 13, 2015, 12:42:09 pm
This was done long time ago: `ToArmorPre`.
Title: Re: [EXE] OpenXcom Extended
Post by: robin on December 14, 2015, 02:58:28 pm
where can i find the required nightly?
i guess i could take out the files from xpiratez mod.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 14, 2015, 06:43:59 pm
Some posts ago I post it in this thread as zip.
Title: Re: [EXE] OpenXcom Extended
Post by: robin on December 16, 2015, 10:58:22 pm
laziness triumph.

could anyone point me to what fixing need to be made to port mod to extended?
not asking about advanced extended-only features, just about converting vanilla stuff correctly.

for example i know (as far as i understand) that HWP ammo work in a different way.
vanilla:
  - type: STR_TURRET
    clipSize: 6
  - type: STR_AMMO
    clipSize: 6
equals to extended:
  - type: STR_TURRET
    clipSize: 1
  - type: STR_AMMO
    clipSize: 6
oops this was wrong actually; they still seem to work differently; maybe because it still uses old nightly as base.

also turning off retaliation for alien races is different afaik.
vanilla:
  - retaliation: false
extended:
  - retaliationAggression: -100


anything else?

thanks
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 16, 2015, 11:29:38 pm
this is two different retaliations. One is responsive for random missions (`retaliation`) second for real retaliation after shooting down ufo (`retaliationAggression`).
Title: Re: [EXE] OpenXcom Extended
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 :)
Title: Re: [EXE] OpenXcom Extended
Post by: AbuDhabi on December 20, 2015, 05:05:29 pm
I'm trying the Linux binaries linked in the first post, and getting segmentation fault (no other errors). What gives?

This is a Linux Mint, and I've got the ubuntu nightly installed via repository. What's the proper way to install the extended version?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 20, 2015, 06:26:51 pm
This repo is probably version 1.0 that should be forgotten. You need proper data from nightly to work with. You can grab it for one of post in that thread (I probably should move it to first post for better visibility).
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on December 27, 2015, 12:54:10 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...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 27, 2015, 01:17:26 am
It can be done. When I have some free time I will do it.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on December 27, 2015, 12:39:22 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... :)
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 27, 2015, 02:55:22 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
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.
Title: Re: [EXE] OpenXcom Extended
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. :)
Title: Re: [EXE] OpenXcom Extended
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 ?
Title: Re: [EXE] OpenXcom Extended
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:
  neutral: false/true ?
Right, this too. It can have some uses over reusing `friend`for them.
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on December 27, 2015, 09:57:14 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.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on December 28, 2015, 09:32:09 am
I can make some of them optional. Theoretically even all of them.

Which features would you turn off if you had the possibility?
Title: Re: [EXE] OpenXcom Extended
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)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on December 29, 2015, 09:04:12 am
Another simple enhnacement idea, for Manufacturing this time: adding maxEngineers setting to an item manufacture project. It would disallow to throw more Engineers at an item than this setting allows (like Stanisław Lem said, making fun of what he called 'military logic': the fact that a single person needs 200 minutes to dig a hole, doesn't mean that throwing 100 people at this job will result in the hole being dug in 2 minutes; a more likely result is people killing each other with shovels).

Same might be done for research (maxScientists; Lem was talking specifically about research, after all, and using physical work just as an example) - not that important in Piratez, as your number of Scientists is limited any ways, but would be immensely useful for vanilla-enhancement mods, like FMP or X-Ops or Hardmode.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 01, 2016, 02:58:36 pm
It bit stupid if fork of my fork create base repo, but we can probably work around this.

If you do it everything correctly, you should have clean fork of OXC without OXCE under:

Code: [Select]
git remote add MeridianRepo git@github.com:Meridian/OpenXcom.git
Then 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/
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on January 06, 2016, 06:30:41 pm
OK, I think I finally managed to do it properly: https://github.com/MeridianOXC/OpenXcom/tree/oxce2.5b-plus-prototypes
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 06, 2016, 06:51:45 pm
Great :)
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on January 10, 2016, 02:39:04 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:


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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 10, 2016, 08:11:04 pm
I think second solution is better because it will allow temporary pickup something else without dropping weapon.

And for current status of my mod. Is very likely that tomorrow I will release new version. It will be still based on old nightly. Next release will be up to date.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on January 11, 2016, 05:10:24 pm
Another small request, if possible... behaviour change for built-in weapons: items with fixedWeapon: true, battle type 0 are never equipped on hand, always in inventory slots, just like they were non-fixed. This can be used to limit carrying space for units.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 14, 2016, 02:13:51 am
This post is sponsored by this music: https://www.youtube.com/watch?v=JzAektg101M

New version is close to finish, some teaser: https://youtu.be/q0-RwIvLUxw

Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on January 14, 2016, 10:10:17 am
Not sure if it has any practical use, but really looks fun :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 14, 2016, 07:50:24 pm
Better question is what consequence of this are. That was only trivial test of that everything work as excepted.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on January 14, 2016, 08:06:20 pm
So I think we are getting into animated sprites with that demo... 
- Reaper's head swaying slowly side to side,
- Boomasaurus drooling
- StarGods shimmering...
just some thoughts.  I have no idea how to tag the frames for the animations and it makes my brain hurt abit just to think about it. ;)
Title: Re: [EXE] OpenXcom Extended
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.

:)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 14, 2016, 08:28:20 pm
So I think we are getting into animated sprites with that demo... 
- Reaper's head swaying slowly side to side,
- Boomasaurus drooling
- StarGods shimmering...
just some thoughts.  I have no idea how to tag the frames for the animations and it makes my brain hurt abit just to think about it. ;)
s*** I thought that nobody will want doing animation for big units and skipped implementing that for them. I need probably add this too,
Title: Re: [EXE] OpenXcom Extended
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. ;)
Title: Re: [EXE] OpenXcom Extended
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 :)
Title: Re: [EXE] OpenXcom Extended
Post by: XOps on January 15, 2016, 09:50:35 pm
Looks interesting. Could always use more animation options. :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 17, 2016, 09:04:21 pm
whole week wasted on fighting on different kind of bugs :/
a) my bugs
b) compiler bugs
c) not existing bugs
But I probably squash all of them.

Maybe I manage to release new version in next/this week (depending if you read this today or tomorrow :) ).
Because I don't update to recent nightly and don't introduce breaking changes, I will probably downgrade next release version number to 2.9 .
3.0 will be based on current nightly and will drop functionality that is redundant to or can be replaced by script engine.
Title: Re: [EXE] OpenXcom Extended
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!
Title: Re: [EXE] OpenXcom Extended
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 :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 21, 2016, 09:41:58 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.

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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 29, 2016, 01:37:19 am
New version 2.9 is ready:
Scripting support in unit graphic (more info in game log with debug on).
`bigSpriteAlt` and `floorSpriteAlt` is now obsolete, will be replaced by scripts in next version.
New property `refNode` used to shared values between items/solders/armors etc.
Option for setting numbers of melee hits done by AI.
Control space usage of soldiers with 2x2 armors in crafts.
Bug fix and small bump of nightly.

[ps]
I fixed broken download link in mod portal, now you should be able to download it.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 30, 2016, 12:55:38 am
First tutorial:
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on January 30, 2016, 09:47:55 pm
@Yankes: on 2.9, I am getting a CTD when "playIntro" is set to true... can you check, if you're getting it too?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 31, 2016, 02:01:55 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?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on January 31, 2016, 02:30:00 pm
Best way is simply compile with debug info and see where crash. And its not strange, I compile using completely different compiler and libraries versions.
Sometimes small difference can easy crash something.
Title: Re: [EXE] OpenXcom Extended
Post by: debuser on February 01, 2016, 01:31:57 pm
Hi Yankes

I am having some trouble getting a properly working binary with xpirates 97D under Debian Linux.

So far I have compiled the 'oxce2.5b-plus-prototypes' branch from  https://github.com/MeridianOXC/OpenXcom.git
When it runs I cannot see  the latest two handed firearm changes or filtering in the craft crew menu. Other odd thing is I am unable to save and then load. It creates a save game but will not show any save game created by this binary in game for me. I am able to see and load save games in game that was made by other binaries.

I'll attempt to attach my binary if you could see if it works for you or if you could share your known working binary that would be great thanks!


Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 01, 2016, 07:59:46 pm
Hi Yankes

I am having some trouble getting a properly working binary with xpirates 97D under Debian Linux.

So far I have compiled the 'oxce2.5b-plus-prototypes' branch from  https://github.com/MeridianOXC/OpenXcom.git
When it runs I cannot see  the latest two handed firearm changes or filtering in the craft crew menu. Other odd thing is I am unable to save and then load. It creates a save game but will not show any save game created by this binary in game for me. I am able to see and load save games in game that was made by other binaries.

I'll attempt to attach my binary if you could see if it works for you or if you could share your known working binary that would be great thanks!
First of all most of this, with you have problems is from Meridian branch. It will be hard to debug someone else code.
Do you used binary based on my branch too https://github.com/Yankes/OpenXcom.git ? (but look out, current version 2.9 is incompatible with xpirates).
Could you prove commit id your binary is build on? Maybe when I will have more free time in this week I will look on your problem.
Title: Re: [EXE] OpenXcom Extended
Post by: debuser on February 02, 2016, 12:24:30 am
Thank you for the reply Yankes. I have tried compiling your repo https://github.com/Yankes/OpenXcom.git but as you said it does not work with x-pirates.
This is really a problem with Merdian's repo, I was under the impression you are already familiar with x-pirates and hoping you already had a working binary. I'll post in the x-pirate thread https://openxcom.org/forum/index.php/topic,4187.msg58671.html#msg58671
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 02, 2016, 12:42:57 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 :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 02, 2016, 01:29:14 am
Right, I forget about this change, but game should still work, not as intended but not crash.
I will need spend some time cherry-pick cherries from your branch :)
Title: Re: [EXE] OpenXcom Extended
Post by: yrizoud on February 04, 2016, 09:48:21 pm
Just wanted to report a funny experiment that I just did : A torch for Piratez, replacing the electro-flare. It's a light source that you can toss around, and you can club people with it and set them on fire. Partytime!

Item battleType needs to be 10 to make it project light source. The "power" stat determines light distance, as far as I know (didn't try something different from a vanilla flare)
Then I copied the #Bayonet segment section from a rifle
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 end
Fire naturally bypasses armor, and has a chance to inflict fatal wounds and flaming status.
(edit: I wanted to share here because only OXCE makes it possible)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 05, 2016, 01:13:23 am
I think its very smart concept of item.
Title: Re: [EXE] OpenXcom Extended
Post by: Aldi on February 17, 2016, 05:26:55 pm
Hi all,

I'm new here so if this is wrong topic please forgive me.

Im using Ubuntu Mate 15.10. When im trying to install libsdl-gfx1.2-4 and libyaml-cpp0.5 apt-get can't  find them.
How can i overcome this problem? Do i need to add some repository?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: R1dO on February 17, 2016, 08:02:48 pm
He's using 15.10. The official channels for that version only provide yaml-cpp version 0.5.2  (and a older version like 0.3 if i remember correct).

I don't know if extended has the same problems with that version, but it could easily mean he/she has to resort to either a PPA or a manual build of yaml-cpp.
Title: Re: [EXE] OpenXcom Extended
Post by: Aldi on February 17, 2016, 08:10:25 pm
ok, now i have libyaml-cpp0.5v5, libsdl-gfx1.2-5 and  OpenXcomEx from mod portal and when i try to run it i get

OpenXcomEx: error while loading shared libraries: libSDL_gfx.so.13: cannot open shared object file: No such file or directory

btw. does OpenXcomEx also supports optons -user/data/config? because when i try to run it with -h , --help or -? i get same error.

Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 17, 2016, 08:22:24 pm
This error mean that binary need older version of library. Probably best way to avoid this is compile binary yourself.
This will need bit more work (around 4-6 bash commands) but will allow grab other version too (like Meridian version of OXCE).
I can guide you Aldi if you want with this.
Title: Re: [EXE] OpenXcom Extended
Post by: Aldi on February 17, 2016, 10:44:14 pm
I built binary and it works now. I had also a little bit confusion with setting up xpiratz but all is up and running now.
Many thanks for advice.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 17, 2016, 11:07:40 pm
Did you use Meridian branch for xpiratz? He adds some gameplay features needed by Dioxine mod (like removing some inventory slots in armores). I do not add them jet to my branch (they will be available in next release).
Title: Re: [EXE] OpenXcom Extended
Post by: Aldi on February 18, 2016, 12:20:55 am
Thanks for info, i'm switching to his branch then.

Another problem occurred..

Now I have two clones OpenXcomExtendedMeridan and  OpenXcomExtendedYankes, both set to master and newest XPiratez (0.97D)
I built binary for both. I lunch it with -user and -data pointing to same directories.
On Yankes's repo there is no right hand slot on solider view, so I can arm pirate only in one weapon in left hand, but this weapon works.
On Meridan's repo game saving is not working but pirates have both hands, but meal weapon doesn't work it can only be thrown.

Should I checkout some tag not just master to make it works? or use Yankes's repo with older XPiratez version?
Title: Re: [EXE] OpenXcom Extended
Post by: Aldi on February 18, 2016, 12:18:12 pm
I guess most of my problems is ymal-cpp version. I can built it from https://github.com/jbeder/yaml-cpp but what tag should I use? release-0.5.0 or newer?
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on February 18, 2016, 05:52:14 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.
Title: Re: [EXE] OpenXcom Extended
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).
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on February 18, 2016, 08:16:09 pm
Thank you very much.
Title: Re: [EXE] OpenXcom Extended
Post by: Aldi on February 19, 2016, 01:13:48 am
I checked out oxce2.5b-plus-prototypes branch and everything seems to works now.

Thanks for help Meridian and Yankes. You are best and fastest tech support I ever met :)

Meridian it would be helpful if could add some note about those branches and maybe this forum link to readme on your repo.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 21, 2016, 04:11:40 pm
I confess that I f*** up stun damage calculation in stun rod. Instead of 100% effective you have random value from 0% to 100%.
This will be fixed in next version (3.0) by introducing new property in damage `ToStunRandom: true` that will be altering how value is calculated.
All damage types except of stun will have true as default.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on February 27, 2016, 02:22:38 pm
Primed grenade indicator in 2.9 is broken.
Fix here: https://github.com/MeridianOXC/OpenXcom/commit/fcfc7158e12f116a4e2718dd1351da5120291f1f

EDIT:
@Yankes: are you compiling windows executable using Visual Studio 2015 or something else? If using vs2015, could you send/link/share me your entire project including everything? I am totally not capable of doing this right...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 28, 2016, 01:36:37 am
I using linux build chain: mxe. This is gcc  packed and configured to output stand alone exe.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 28, 2016, 05:43:42 pm
Thanks, I will look on this.
Title: Re: [EXE] OpenXcom Extended
Post by: Countdown on February 29, 2016, 01:07:14 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.

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!
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
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.

I also think the feature being able to shoot unconscious units and kill them is a big plus. Is there a way to add a death sound for this in the rulesets? If you are shooting at an unconscious alien, you might be unsure if you hit/killed it since there is no sound. You have to step on it and look at the inventory. Not a major thing, but just curious if it was a feature in the rulesets to change the properties of a corpse.

Speaking of corpses, I saw this thread from a long time ago and it seemed like individualized corpses (for race/gender) were on their way to being added: https://openxcom.org/forum/index.php/topic,523.75.html

What ever happened with that? Is that moddable too with the current rulesets?

Thank you!
This isn't separate sprites but recoloring. And it should work right now. And in future you will have full control over that sprite to show in item (as corpse is only one use case).
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on February 29, 2016, 11:41:20 pm
Any chance for adding function for gibs animation/floorob? Current overkill anim is kewl but some variety would be even better :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on February 29, 2016, 11:55:33 pm
Right now different corpse if off the limits but animation of death is fully customizable in 2.9, in 3.0 it will probably affectable by kill weapon.


[ps]

This is true, but in real life you'd be able to tell if you put a bullet in their head haha.

I tried adding a death sound to the corpse in item.rul and that didn't do it. I also tried to use "explosionHitSound" and no luck either (not that I expected that one to do it). Would there be another way?
do you add death explosions? If not it would be hard to get it. Overall at some point I had plans to add screams but now I working on other things and it was push back to other time.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 01, 2016, 09:51:16 pm
Yes, they use same palette (with exception of last 15 index in inventory), but they need use exactly same colors to work with recoloring.
Working example is normal solders from OXC, Extended add same recoloring to corpses and inventory items. If it work for unit it should work for items and inventory.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on March 01, 2016, 10:16:06 pm
look here:

https://falkooxc.pythonanywhere.com/palconvert

the recoloring routine takes one of the colors (horizontal rows) and translates it by adding a fixed number, so say row 4 is recolored to row 7. For your hair recolors to work, both males and females on the spritesheet must have hair composed of one and the same color (row), with no rogue pixels.
Title: Re: [EXE] OpenXcom Extended
Post by: Countdown on March 02, 2016, 12:28:52 am
I think maybe I'm not explaining my problem very well. I understand how to do the color replacement with the armor ruleset, I just don't understand how to carry over those changes for corpses/inventory. See the screen shots and ruleset code below. The first part works for the live units, but once they are corpses the color change stops:

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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 02, 2016, 12:57:36 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).
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on March 02, 2016, 01:07:35 am
You cannot auto-recolor Inventory pics.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 02, 2016, 06:52:32 pm
Sorry, game behave a bit different than I though. Because I now testing recoloring scripts this functionality "work for me". I forget that I never implemented recoloring (using properties form basic OXC) for items without scripts :/
Again sorry for confusion.

Work around to enable items and inventory recoloring is adding in armor:
Quote
    recolorScript: |
      unit.getRecolor i0;
      add_burn_shade i0 burn shade;
      ret i0;


Title: Re: [EXE] OpenXcom Extended
Post by: Countdown on March 02, 2016, 10:17:22 pm
Cool, I will try that out. Thanks again.

UPDATE: Yankes, that worked well. Looks great.


UPDATE #2: Question for Yankes or anyone else who might be looking on. I think I already know the answer is no, but can you set a new inventory portrait for a soldier based on his rank? (I'm not talking about color changing script since I assume that isn't doable, I'm talking about using the extrasprite ruleset for the MAN.SPK files.)

If you want to set a different colored armor for the gender/race that is easy. Just modify the extrasprite rulset and switch out the vanilla armor for the image you want ... done.

But could you do this based on the unit's rank? I don't see a way. You would need an if/then statement (not doable in YAML I don't think) and I must be missing it because I can't even find rank as a property in any of the rulesets for XCOM soldiers.
Title: Re: [EXE] OpenXcom Extended
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.)

If you want to set a different colored armor for the gender/race that is easy. Just modify the extrasprite rulset and switch out the vanilla armor for the image you want ... done.

But could you do this based on the unit's rank? I don't see a way. You would need an if/then statement (not doable in YAML I don't think) and I must be missing it because I can't even find rank as a property in any of the rulesets for XCOM soldiers.
Right now not. But I think about way to add it.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on March 11, 2016, 03:31:20 am
What is the plan for the stun damage randomizer bug? I like how it works now, allowing for hits to have a random secondary stun damage. Maybe leave that extra 0-100% Stun roll be? Or make it optional? Actually while this stunts stun weapons (which I had to compensate by powering them up), it does work great for secondary stun damage.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 11, 2016, 07:12:06 pm
Fix for bug will be new option for each damage part (stun/hp/morale et..) that define that is it randomized.
Stun damage type for defualt will have not random value but other damage types will randomize it.
Sneak peek from next version ruleset:
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on March 11, 2016, 10:14:14 pm
Maybe one example for explanation:

Current in 2.9:
Cattle prod has base damage 70... meaning range from 0 to 140.
Let's say we roll damage 60.
This 60 roll will not do anything.
Another roll between 0 and 60(or less?) will be done for stun damage.
Let's say the roll will be 13.
Final total stun damage (before armor reduction) will be 13.

New in 3.0:
Cattle prod has base damage 70... meaning range from 0 to 140.
Let's say we roll damage 60.
This 60 roll will not do anything (yet).
Another roll between 0 and 60(or less?) will be done for stun damage. There will be no second roll (by default).
Let's say the roll will be 13.
Final total stun damage (before armor reduction) will be 60.

@Yankes: please correct me if I understood it incorrectly

EDIT: weapons with other damage type than stun will not be affected... they will still have random stun effect (by default)... same as now... for example gauss rifle with power 70 (range 0 to 140) will roll damage 60 and do 60 piercing damage. Then it will do another roll for stun, let's say 13 and do additional 13 stun damage.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 11, 2016, 10:22:52 pm
Exactly.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on March 11, 2016, 11:26:41 pm
Good. But I will keep Cattle Prod using the current ('bugged') formula, isn't it OP anyway? :)))
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 11, 2016, 11:32:03 pm
If you change option, then yes.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on March 14, 2016, 10:54:40 pm
Hi Yankes!

I was just getting ready to create a mod for stunned corpses.... then I saw this:

" `bigSpriteAlt` and `floorSpriteAlt` is now obsolete, will be replaced by scripts in next version."

Can you help me out?  What would I need to know to get this to work?  (just be patient? )  ;)

Cheers, Ivan :D
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 14, 2016, 10:57:46 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.
Title: Re: [EXE] OpenXcom Extended
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!
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on March 17, 2016, 11:16:08 am
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)
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on March 19, 2016, 11:19:53 am
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.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on March 19, 2016, 05:27:41 pm
Just wanted to chime in here that I've built a mod for PirateZ based on the bigSpriteAlt: functionality of OXCE 2.9.  (I hope the jump to scripting in 3.0 doesn't break my brain, but if it does, I'll ask Yankes for help. ;)  )


https://openxcom.org/forum/index.php/topic,4424.0.html


Cheers, Ivan :D
Title: Re: [EXE] OpenXcom Extended
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).
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 22, 2016, 01:33:41 am
Small update on current progress.

Right now I'm finishing basic functionality required for new features. Right now only thing left in it is automatic self documentation of scripts.
When I done it I will finally start implementing new features. I expect that will take me around 4 weeks to release 3.0 version.

Some features that should be available in 3.0 (some already implemented, other still in plans):
- items are now available in scripts
- you can get items held in hands of unit (rest of inventory or ground is unavailable)
- custom rulesets properties of items and units available in scripts
- bonus stats will be able to use scripts for calculation of bonuses
- custom recoloring and switching graphic for items
- scripts access to unit reactions and maybe visibility too
- special scripts that will handling unit damage and defense
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on March 24, 2016, 04:05:15 pm
1. Yes, that'd be good. Default armor is always for free anyway, so I can't see any problems.

2. It should work just like when you don't have enough armor sets and try to equip by r-clicking (ignore command).

3. Yes, it would just look cleaner that way.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on March 25, 2016, 01:51:47 pm
1. Done
2. Done... but please test. It was too much work to remove STR_NONE_UC from all rulesets, so I didn't test it.
3. This can be done without code changes actually, just change translation from this:
STR_ARMOR_: "ARMOR> {0}"
to this:
STR_ARMOR_: "{0}"

Download later in the evening.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on March 27, 2016, 10:17:24 pm
Hi Yankes,

I managed to compile and run OXCE+ on Kubuntu successfully... using the guide on UFOpaedia.org.

Can you tell me/share how to compile a Windows executable under Linux with everything inside as you do it?
If possible, an idiot-proof guide... I am a bit of a Linux n00b. And by a bit I mean I am a frikkin' amateur.

Cheers,
Meridian
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on March 28, 2016, 01:09:35 am
one word: `Makefile.mxe` this is make file I used for compiling exe. It require too components, yaml and mxe build chain.
To work properly it need one folder with `openxcom`, `yaml-cpp` and `mxe`.

I add some scripts that I prepared for "one-click deployment" (in case of Linux this is one script :D). You need fix paths and branches in it but overall structure should work for you too.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on March 28, 2016, 01:01:59 pm
Excellent... worked on first try... thank you.
Title: Re: [EXE] OpenXcom Extended
Post by: g5-freemen on April 04, 2016, 11:30:51 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+
Title: Re: [EXE] OpenXcom Extended
Post by: Countdown on April 04, 2016, 11:54:06 am
Not a stupid question IMO, but I'm biased as I asked the same thing not to long ago, haha. Here is the response I got. There is some more explanation in the thread this quote comes from as well (plus obviously a ton more info in the thread we're in now).

OXCE is Yankes' OpenXcom Extended version.  It opens up alot of features and customization for modders.
OXCE+ is Meridian's Branch of the above, that he coded for use with PirateZ, but it can run without PirateZ, though other mods may not take advantage of its capabilities.  You can download it from the first post here: https://openxcom.org/forum/index.php/topic,4187.0.html

As far as downloading the latest version of OXCE:

Current working branch:
https://github.com/Yankes/OpenXcom/tree/OpenXcomExtended

Download available on mod site (require latest nightly):
https://www.openxcom.com/mod/openxcom-extended

Backup:
https://www.mediafire.com/folder/w07p0ibc985kd/OXCE

Forum thread:
https://openxcom.org/forum/index.php?topic=2915.msg31641#msg31641
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: g5-freemen on April 04, 2016, 01:14:36 pm
Thanks alot, and one more question - OpenXcom Extended include all changes/fixes from latest nightly builds of standart OpenXCOM?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
I will prepare a full download later today.
How about all data files with EXE ? And does it so difficult to place it (EXE + data files) together?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: g5-freemen on April 12, 2016, 06:11:14 pm
I play OpenXCom a long time, everythin OK (latest nightly)
I drop OpenXcomExPlus29.exe to the game folder and try to run and get error. What i do wrong?

[12-04-2016 18:08:49]   [INFO]   Data folder is:
[12-04-2016 18:08:49]   [INFO]   Data search is:
[12-04-2016 18:08:49]   [INFO]   - C:\Users\user\Documents\OpenXcom\
[12-04-2016 18:08:49]   [INFO]   - F:\games\openxcom
[12-04-2016 18:08:49]   [INFO]   - F:\games\openxcom
[12-04-2016 18:08:49]   [INFO]   User folder is: C:\Users\user\Documents\OpenXcom\
[12-04-2016 18:08:49]   [INFO]   Config folder is: C:\Users\user\Documents\OpenXcom\
[12-04-2016 18:08:49]   [INFO]   Options loaded successfully.
[12-04-2016 18:08:49]   [INFO]   Scanning standard mods in 'standard'...
[12-04-2016 18:08:49]   [INFO]   Scanning user mods in 'C:\Users\user\Documents\OpenXcom\mods'...
[12-04-2016 18:08:49]   [INFO]   Mapping resource files...
[12-04-2016 18:08:50]   [INFO]   Resources files mapped successfully.
[12-04-2016 18:08:50]   [INFO]   SDL initialized successfully.
[12-04-2016 18:08:50]   [INFO]   SDL_mixer initialized successfully.
[12-04-2016 18:08:50]   [INFO]   Attempting to set display to 640x400x8...
[12-04-2016 18:08:50]   [INFO]   Display set to 640x400x8.
[12-04-2016 18:08:50]   [INFO]   Loading data...
[12-04-2016 18:08:50]   [INFO]   Loading font... Font.dat
[12-04-2016 18:08:50]   [ERROR]   bad conversion

--- posts merged by your friendly neighbourhood moderator-nya~! ---

Replace original OpenXCom font.dat by font.dat from data29.zip, game runs (OpenXcom Extended).
OpenXcom crashed.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on April 12, 2016, 06:42:49 pm
The executable is simply not compatible with the data files from the latest nightly... because it is not based on the latest nightly, but on an older version (couple of months old).
You need different data files.
Title: Re: [EXE] OpenXcom Extended
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).
You need different data files.
For me there is only one problem - font.dat
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on April 13, 2016, 01:44:39 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?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: g5-freemen on April 13, 2016, 05:23:59 pm
OpenXcom Extended also not compatible with Soldier Diaries 1.0 mod as i understand? :(
Title: Re: [EXE] OpenXcom Extended
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)
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on May 14, 2016, 06:12:38 pm
@Yankes:

Would you mind looking at this bug: https://openxcom.org/forum/index.php/topic,4637.0.html when/if you have some time... I don't understand the dogfight code well enough to find what's causing it. It's nicely reproducible.

Also, if you'll be going through dogfight code, maybe have a look at this too: https://openxcom.org/forum/index.php/topic,4058.msg64352.html#msg64352
This one is unfortunately not reproducible... but many people (including me) experience it relatively often. Maybe you'll see what could be wrong...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 14, 2016, 06:41:51 pm
I will check it out.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on May 25, 2016, 05:13:33 am
Q. how do I make the psi-amp special attack deal damage? I managed to get it to work, but it doesn't do any visible damage... do I need to define this by damage bonus and damage alter? I have this so far, but it doesn't work...

Code: [Select]
    psiAttackName: STR_PSI_CUSTOM_ATTACK
    accuracyUse: 7
    damageBonus:
      psi: 0.02
    damageAlter:
      ToHealth: 1.0
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 25, 2016, 09:26:47 am
Its need be defined like as in normal weapons e.g. you need add power, damage type, hit animation. Aside of that you need add name of attack that enable it in action menu.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on May 25, 2016, 01:23:44 pm
Ah so it does need a damage type! Ok got it now. But it still does work through walls, right? :)
Iif this works I will redo some of the magic wands etc., psi-amp attack (LoS-only if needed) will be so much better that using bullets! Sweeet. Damn there still are depths of OXCE I didn't discover :)
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on May 31, 2016, 11:02:10 am
Hi Yankes,

I see you've cherry-picked a few of OXCE+ commits into OXCE.

Although, that is the ultimate goal, please don't take anything GUI-related at the moment... I want to refactor GUI-code after OXCE 3.0 (there are missing translations, missing tftd support and a lot of hardcoded colors and constants). Also I want to remove some stuff, which is now either obsolete or turned out not to be useful.

On a similar note... have you started with merging OXC master? Don't want to rush you or anything, just want some indication so that I can plan also my activities a bit better...

Meridian
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 31, 2016, 08:03:45 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.
Title: Re: [EXE] OpenXcom Extended
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)
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on May 31, 2016, 11:44:52 pm
25edd7b is 2nd of January, right?
I'll wait a bit more then, still 6 more months to merge :/

EDIT: also to your attention: https://github.com/stiansel/OpenXcom/commit/b8a94c8c581d6a804c9307b18168cb3f476ed739
Do you have some commit from master that are you interested in? I will for now keep away from commit with AI changes because I will need rewriting my changes to fit new system (it could be trivial or it could be hard). I could grab bit more commits if they merge smoothly.

That's great news! There's a number of features that would be really useful for Piratez or X-Com Files:
- Soldier Diaries
- spawning UFO by mission
- destroyItem command
- defining waypoints (if possible, by soldier stats too)
Right now only Soldier Diaries are in. For rest I need check, "destroyItem" is not because its recent commit and I'm now around 300 commits behind (down form 800).
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on June 02, 2016, 10:40:05 am
Another question regarding custom psi attacks... the accuracyBonus. What are the defaults for Mind Control and Panic, so I could fine-tune the special attack accuracy?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 02, 2016, 09:55:42 pm
Psi have 4 bonuses:
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 25, 2016, 12:08:23 am
New version 3.0 is ready (based on 2016-01-02 nightly)

Backported game machanic changes from Meridian OXCE+.
Fix stun damage calculation and add random for random option for final stats change by damage.
Refactored script handling.
Script support in reaction atack chance calculations.
Some light handling improvments.
New recolr and replace script graphic option for items.
Option for global events shared by scripts.
Custom tags that have user defined values.


Scripts was improved a lot compared to previous version. First part of game engine that was exposed to script is reaction handling.
You can made unit immune to reaction shoots or reaction shoots have lesser chance to happens if unit is far away.

In next version I plan expose unit damage, visibility and allow do custom actions on turn end.
Title: Re: [EXE] OpenXcom Extended
Post by: begri on June 25, 2016, 10:46:39 am
Can someone make the extended version on Android?

Gesendet von meinem SM-T800 mit Tapatalk

Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on June 25, 2016, 12:39:16 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?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Vesparco on June 28, 2016, 02:12:11 am
Hi there,

I'm hurting my head with an idea to work on and I have to point out a feature/request that may be interesting.

In the new ruleset for facilities, could it be implemente an oposite of the following rule?
    "requiresBaseFunc: [ ]   #List of custom IDs that are require to build this building in base."

My idea is:
    "ForbiddenbyBaseFunc: [ ]   #List of custom IDs that forbids the building of this building in base."

What are the advantages of having this functionality:

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

Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on June 28, 2016, 07:19:56 pm
Yeah, this looks like a very useful thing. One building per base mechanics would have its perks!
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 28, 2016, 07:27:32 pm
I probably could add it, right now I don't see any possible complication that it could cause.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on June 28, 2016, 07:53:47 pm
So, if for example A forbids B... I can just build B first and then A. How are you gonna stop me?
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
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".
Title: Re: [EXE] OpenXcom Extended
Post by: Vesparco on June 29, 2016, 02:14:24 am
That depends if you can define multiple "cases" with forbid (as with the example of the requirements of the "study" facility in Piratez extended).

Also important, it depends if a building under construction already gives its trait for such case (forbidding), otherwise you have a hole in the method.

As pointed out by Solarius, if you give facilities a trait of "unique" and at the same time they forbid themselves if the trait "unique" already is given by another facility in the base, you have a unique facility. If some facilities share the same approach, then is a "choose one facility".

BUT (big but), if you also start branding other facilities with a common trait (let's say, branchA) and you forbid them with another one (branchB), you can segregate "families" of facilities, forcing the specialization.

in such conditions you could define "common", "branchA", "branchB".

in terms of game mechanics, you could recycle the system in each branch to your will, isolating their behavior with the rest of the game.

As this last statement is kind of gray I put the idea I've been going around theses days.

"Casino Base".

One unique barrack with space for X people, Y storage and Z work spaces. Branded "unique" and "BranchB". (business HQ). It is the start of the branch and that inmediately forbids "BranchA".
Everything that does go with the flow and breaks the mechanics go branded "branchA", including workshops, quarters and stores.
- Storage becomes dedicated to storing a merchandise or HWP called "Criminal roller" (not transferable). Each give and income but occupies 1 point of storage. Dedicated facilities gives more storage (accommodations).
- Manufacturing becomes specialized, it creates this "merchandise" or transforms other materials. I can use the quantity of "merchandise" to set a minimum value in order to be able to do other stuff. Additional facilities give more manufacturing options, all of them under margins of "control" thanks on the limitation on workshop space (the cash cow can't skyrocket unexpectedly). Additional facilities gives additional manufacturing projects (taverns, variety shows, safe depots, racing garage, parking slot, underground arena, Supervillain comms room,etc). You can tier them, you can bind them by research or by requiring another room trait (sky is the limit).
- Living space becomes a tradeoff, If the base is under attack you need soldiers but the quantity and their equipment impacts on the revenue given by the "merchandise" and the runts working in the projects. Having the merchandise going around during assaults (if HWP) could go directly into a monetary and score loss.

Sickly conceived, yes, I know. But this opens a lot of gameplay options for everyone to conceive  ;D



Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on June 29, 2016, 08:00:25 pm
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.
Title: Re: [EXE] OpenXcom Extended
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  ???
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 01, 2016, 09:29:23 pm
I prepare short tutorial for OXCE scripts. Before expanding it more I would like hear some feedback.
Is it easy to understand? What you would want be more elaborate? Anything is missing?



Tutorial of using scripts

List of available function and vales in script is available in log file with debug mode enabled.

Assume you want add reaction to melee attacks.
Then you can do it in two ways:
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 to
react (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`.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 02, 2016, 04:45:27 am
Thanks for the tutorials on scripting, Yankes!  I do have a question about the ability to do alternate graphics for corpses....

Let me try to think how this would be handled....

Say we want to know from looking at them which were alive (stunned), which were wounded (bleeding), and which were dead. 

Could we do this on mouse over?  say hover over a corpse floorOb and if its bleeding, it Pops text "wounded" (from a defined STR_WOUNDED definition) or "Stunned" etc,?   Or maybe by placing another graphic over it?   "ZZzz" for stunned "++++" for wounded, and nothing for dead, etc.

At a minimum could a system of multiple different graphic versions for each item would similar to the altBigsprite that I'm currently using in the Alt_Corpses mod for Piratez?   If so, how would that work, could you use the file name convention to define it, ...

Here corpses (bigObs) are dead (b), stunned (bs), and wounded (bw).
Code: [Select]
Resources/Corpses/PIR_1_b.png
Resources/Corpses/PIR_1_bs.png
Resources/Corpses/PIR_1_bw.png

Alternately could we do some of that weird glowy stuff for the floor objects, ie, flash them blue glow for stunned, red glow for wounded, or even pulse an outline around them? :)

I hope this isn't too much of a ramble, and thanks for the amazing work externalizing these functions.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 02, 2016, 05:19:48 pm
I think in future I could add option for that script could react to if current tile is selected by mouse.
Adding text is impossible and for long time will be. You can only change sprites.

I'm now working on implementing example scripts that will change corpse ground image based on unit state (stunned/wounded/dead).
Whiled doing that I find couple small bugs and missing features needed to do it. In beginning of next week I will release new version that fix that problems and allow crating fully functioning corpse replacer. With that I will post example script that will implements this functionality.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 03, 2016, 02:37:01 am
Hey Yankes,  I was curious if the capability from the nightlies to set the number of waypoints for a guided missiles made it into your latest version of 3.0?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 03, 2016, 12:26:39 pm
Not yet. I will merge recent changes from master at end of this month or beginning of next.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on July 03, 2016, 07:19:37 pm
I am getting following errors when trying to compile oxce 3.0 in visual studiio 2015... any idea what's wrong?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on July 04, 2016, 01:49:02 pm
I have upgraded my piratez campaign to OXCE 3.0 (without +) and there are some glitches:
1. Clicking on "New project" takes about 30 seconds...
2. When I go into craft and inventory screen to equip my soldiers... after clicking OK to return back... I get crash to desktop

This was just 5 minutes of testing, I'll do more tests in the evening and report them in this post...

EDIT1:
3. when I transfer a soldier from one base to another, after arrival the game seems to get in an endless loop and stops responding
4. actually just letting the time pass on 1hour or 1day results in application hanging quite soon (with 100% CPU usage)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 04, 2016, 06:16:02 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?
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on July 04, 2016, 07:09:29 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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 04, 2016, 09:01:55 pm
https://github.com/Yankes/OpenXcom/commit/dcd84b09cd25a3090e361d8240c9e8251e5c5f29
This commit should fix VS bug. Meantime I'm working on rest of bugs.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 04, 2016, 10:05:56 pm

Some time ago a similar bug was fixed in the main openxcom branch.
https://github.com/SupSuper/OpenXcom/commit/ab552fb0aa7b16ef29f3c178bddcbb0b9546903b
Thanks, you save me some hours of work to figuring out this bug :)

[ps]

Ok I probably fixed all this bugs. Geoscape hanging is because each research project try find alien with that same name and this cause new line in debug log.
This is VERY slow. Today or tumorrow I will release new version 3.1 with bug fix and some new functionality.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on July 05, 2016, 09:10:58 am
The compilation on VS2015 with the fix works now, but when I tried to merge the whole branch I got several errors because of mismatch between std::set and std::vector where getProvidedBaseFunc is used (https://github.com/Yankes/OpenXcom/commit/ad27f8deefb69a3cc8797a138478635f5ed22a7e). Sometimes it's set, sometimes vector.

Also, you may want to rename forbidenBaseFunc to forbiddenBaseFunc, just for spelling correctness before you release 3.1 :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 05, 2016, 01:58:46 pm
please cherry pick only one commit, I push my working copy of 3.1 and one bug slip in it. Sorry for not saying this clearly previously.

[ps]

https://github.com/Yankes/OpenXcom/commit/5dad96d0c2d955b1df02fdee4516a5dd08f88aeb
I push commits that fix bugs that you encounter. I prefer if you cherry-pick then because I don't finished yet 3.1. It will take me around day to finish it.
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
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.

Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 07, 2016, 03:48:28 pm
This is script that will work in 3.1 that allow altering corpse graphic based on unit state.
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 07, 2016, 10:45:03 pm
New version 3.1 is ready:

Base building can now prevent building other buildings.
New tag type that store other mod id.
Option for changing defualt unit light radius.
New functions exposed to script.
Reaction scripts have now information about runing or strafing of target.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 07, 2016, 11:11:06 pm
Some questions about Scripts:

Can I have the Script in its own separate .rul file in the mod folder, or does it need to be included in the .rul file that calls the script functions?

Second: in your corpse replacement script example:  Will this same script work to define both FloorObs and BigObs?   or would something here:
Code: [Select]
if eq blit_part blit_item_floorneed to be updated for the BigObs?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 08, 2016, 12:35:50 am
Some questions about Scripts:

Can I have the Script in its own separate .rul file in the mod folder, or does it need to be included in the .rul file that calls the script functions?

Second: in your corpse replacement script example:  Will this same script work to define both FloorObs and BigObs?   or would something here:
Code: [Select]
if eq blit_part blit_item_floorneed to be updated for the BigObs?
right I did it only for FloorObs. You probaby need copy paste this `if` to `end` replaced `getSpriteOffsetFloorob` with `getSpriteOffsetBigobs`.
Add new tags that will store index for bigobs.

And for where script should go. You can place in any `.rul` file, but in each file you need add `extended->tags->RuleArmor`. If armors and script would be in different files you need copy this tags to both files.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 08, 2016, 01:13:26 am
Okay, I think I have it.   Here is my proposed script:

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
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 08, 2016, 01:41:17 am
You made couple of mistaken, here fixed 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;

How you choose sprite indexs? In what mod you plan add this graphics?

[ps]

New version, previous had bug.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 08, 2016, 02:00:14 am
Awesome, Yankes! Thanks for spotting those!  I knew you would be able to spot any mistakes I made there!

I'll be working the alt-corpses up for Piratez.  It will be a stand alone mod, so I'll create my own sprite index for the mod (using "current") as the overall index for sprites in Piratez is very extensive.  I'll number the floor obs in the 1000s and the big obs in the 2000s or vica versa.

Also: Now that this functionality is in 3.1 has the "bigSpriteAlt"  (and floorSpriteAlt?)  been deprecated?  Or will it still be there for a while?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 08, 2016, 01:07:26 pm
"bigSpriteAlt" was drop in 3.0.

And for sprites, if you choose value bigger that last index in piratez it should work, but need be less than last+1000 otherwise you will overlap with next mod.
Good thing is that you can easy split resources part into two mods and only define tags in other to have same functionality.

[ps]

btw I can take couple of small request for new functionality. I plan doing couple of small releases (3.2 to 3.4) and one big one 3.5 with merge of current master.

[ps2]

@ivandogovich I update script again because I made bug in it too.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 11, 2016, 04:22:52 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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 11, 2016, 07:01:50 pm
Ack, damagetype overrides? So I need to make the custom shared setting with every possible property set in the damageAlter, including res type, damage roll, blast propagation etc? Since you can't have a weapon with an undefined damage type?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 11, 2016, 07:38:33 pm
`damageType` is only for backward compatibility, this is why he always override `damageAlter`.
Setting `damageType` set default `damageAlter` and `blastRadius`. If you set in one node `damageAlter` and `damageType` then `damageAlter` will override default values from `damageAlter`.

Some example:
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`.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 13, 2016, 03:38:41 pm
Ack, unfucking everything line by line still looks less work-intensive than either of this: I'd need to add lines to every item PLUS make script declarations (which is sort of black magic - I have no idea about traps like damagetype overriding damagealter). What would really help is moddable default damage settings. Thanks anyway.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 17, 2016, 06:50:06 am
Ok, I'm at the point of trying to test the Alt-Corpse script.   

I've created a script for both floorobs, and bigobs.  For this test, I've trimmed it down to just floorobs by commenting out the bigobs portion.
The script is included in the code section below.

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.
Title: Re: [EXE] OpenXcom Extended
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;
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 17, 2016, 05:09:41 pm
Thanks a ton, I knew it was probably something simple. :)
I must have gotten my version messed up.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 17, 2016, 06:17:38 pm
Ok, I tried out the new script (thank you).  New Battle Generation consistently crashed for me.  The final error in the log is:

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. 

I'm attaching a verbose log file to see if this helps.   Thanks for helping me trouble shoot this!
Ack!  The log file is too large to go up as it is. Let me try to .zip it.

Edit: also including the save file.

Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 17, 2016, 06:34:10 pm
This is not "my" bug, "[ERROR]   Map Script not found". Do you have up to date xpiratez version?
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 17, 2016, 08:24:30 pm
Do your game work without this script?
Did this script compile correctly, no errors are reported in log?
Did script run at all, you can test it by adding line `debug_log 1 1;` on top of script after declaration of variables.
If it work then you will get new log info in game log with two "0x1" values.
If you see it do unit have correctly defined tags for it? You can move `debug_log` to other lines to see if this place is executed by script.
Something like that:
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.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 18, 2016, 05:15:57 am
Ok, I've been trying a few things. 

First I read back through all the posts we have exchanged about this script.  One of the things that you mentioned was that the

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: int

Despite this, I'm still not getting it to work.  Upon trying to load my Bandit Pogrom save, I get a CTD.  Nothing shows up in the .log file.

I suspected that maybe my images weren't formatted with the correct palette, so I ran them through Falko's sprite tool to "fix" the battlescape palette.  Still had the same issue, so I've been trying to use your debug_log tool, but I get failures everytime I try to use it.

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. :(
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 18, 2016, 11:06:50 pm
Ok, I did a run, with debuglogs salted in the script.

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?
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 19, 2016, 12:31:06 am
I've refined it a bit more.

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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 19, 2016, 01:13:37 am
Could you upload whole mod, or at least test part that I could examine exactly what go wrong?
It bit strange that this two lines could crash.

BTW debug_log can output some values like: `debug_log test sprite_index`. Useful is script do something complex and you want know partial results.
Another thing is if you have some suggestions about improvements or additions to scripts?
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 19, 2016, 01:34:24 am
I'll upload the mod and the current save I'm using for testing.  I wish I had a vanilla set to pass you for testing but this is all X-piratez.

As part of testing I disabled my separate script.rul file and add the script part directly into the items.rul file that sets the script values for each of the armors.

With the sav file, you have about 4 swipes with the stun baton to take down the ratman in front of you.  I just reload and try again.

As far as improvements or additions to these scripts....  I'm still trying to completely understand them, and it feels like I only grasp about 40%....

Like I understood that you said debug_log could accept two ints, but not what they mean.  I increased the first number to differentiate them through the script, but just left "1" as the second number.  I suppose that just gave it a value to return if it was successful?  Also, I didn't realize how the "test" parameter would work with the debugger too.

Some thoughts I had that could be done with these scripts though, how about recoloring the floor sprite to indicate these different states.  Gray for dead, pink for wounded, blue for stunned.... etc.   Also, with the ability to script for unit morale, it seems possible to set up a marker for "panicked" units much like what XCOM Apocalypse had.

Edit:  I also have no clue as to what the initial "- Offset= 1" line is about. ;)

Edit 2:  Also, I got errored results inserting "debug_log test sprite_index" :

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;'
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 19, 2016, 02:05:39 am
I will test it tomorrow.
Offset is order what this script is call if multiple scripts are defined.
`debug_log test sprite_index;` would be working if you define variable `test`.
e.g.`debug_log temp sprite_index;` will show current temp and index.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 19, 2016, 07:52:35 pm
I was looking through the various versions of the script that I've been playing with and I noticed a line:

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?
Title: Re: [EXE] OpenXcom Extended
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:

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?
This would be needed if you override default script handling in armor. This would work only for this one not for all armors like global scripts.
Script defined in armor is call with offset 0 and its responsible for default behavior. Your script is called after that (if you set offset to -1 you will be call before it).
`sprite_offset`is not zero only when scripts are call for selecting hand objects sprite. It will hold value of rotation of unit.

[ps]
@ivandogovich I find bug in my code, its why game crash because it not apply correct mod offset to index surface. I will fix it tomorrow.
Title: Re: [EXE] OpenXcom Extended
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!)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 20, 2016, 05:56:03 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.
Title: Re: [EXE] OpenXcom Extended
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).
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 20, 2016, 06:21:59 pm
Thats a really good point, Dioxine!

By the way, speaking of grenades, I've noticed something unusual recently with explosions.  When I toss out smoke grenades, it appears that the explosion is offset from the grenade object.  My impression is that the center of the explosion graphic is located a tile or two down from the grenade location.  This also strikes me as a change from earlier versions of OXC/OXCE etc.

Different question:  I got to thinking of the Overkill issue, and creating a mod to turn those corpses into a pile of ash. :)

What sort of value should the script test for in BattleUnit.getOverKillDamage ? is it a binary value? 0 = not overkilled, 1 = Overkilled?

So the code might look something like this?
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;                                                             
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 20, 2016, 07:27:45 pm
Thats a really good point, Dioxine!

By the way, speaking of grenades, I've noticed something unusual recently with explosions.  When I toss out smoke grenades, it appears that the explosion is offset from the grenade object.  My impression is that the center of the explosion graphic is located a tile or two down from the grenade location.  This also strikes me as a change from earlier versions of OXC/OXCE etc.

Different question:  I got to thinking of the Overkill issue, and creating a mod to turn those corpses into a pile of ash. :)

What sort of value should the script test for in BattleUnit.getOverKillDamage ? is it a binary value? 0 = not overkilled, 1 = Overkilled?

So the code might look something like this?
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;                                                             
Unit do not spawn corpse after overkill, but you can modify corpse unit that was close to evaporating simply looking on current hp.
Over kill is amount of current negative hp that surpass durability of "corpse".
Code: [Select]
overkillDamage =  -curr_health - max_health * overKill
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 20, 2016, 11:24:05 pm
New version 3.2 is ready. Not many changes, primary bug fix and some improvements for script.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 21, 2016, 02:00:38 am
Thanks a ton! Its working! :D  Now just to clean up all my rulesets. :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
Post by: Starving Poet on July 22, 2016, 12:15:32 am
Since throwing distance is determined by weight of the object and a unit's strength - make the falloff setting affect it via percentage.   Then you can just define the max percentage allowed before falloff goes into effect.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 22, 2016, 01:52:45 pm
Yeah something like this... a single global setting with '% range' which sets from which point the dropoff for throwing starts (at 100, no dropoff, at 0, immediately), another setting with '% accuracy at max range', again from 0 (drops to 0 at max throw range) to nominal (100, accuracy as from close range).

Also... Something's not right. I have this code:
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...
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 22, 2016, 07:32:05 pm
I can add this two properties for throwing.

And for radius, it always been caped on 11 for non fixed radius. Looking through history I don't see anyone changing this cap.
I think, I could add new item property that will allow changing this cap.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on July 22, 2016, 09:09:30 pm
I'd like the cap removed, please. Or better yet, make settable through ruleset (I can up it to 30-40 and be happy)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 24, 2016, 02:37:28 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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 27, 2016, 06:44:34 am
Ugh. Popping in with more challenges with corpse switches.  Bigobs this time.  Yankes, can you look this over and see if I'm messing something up?

This is the error I get at a CTD when trying to switch to an inventory view with an corpse that should be switched on the floor.
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. :)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 27, 2016, 07:35:23 pm
It is working for me. Could you run only your mod and piratez and see if it still crash?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 27, 2016, 09:04:06 pm
As you have different mods then `CORPSE_SWITCH_RESOURCES_MOD` need be separated for both modes because graphic is stored in different mods.
Second mod override it ad pointing to wrong one causing crash.
Title: Re: [EXE] OpenXcom Extended
Post by: ivandogovich on July 27, 2016, 09:09:33 pm
I have each mod in separate folders (so they load independently) and they are both set to

CORPSE_SWITCH_RESOURCES_MOD: current.

Can I specify the mod by name then, or by rulefile.rul ?  I don't want them to pull resources from the master (piratez in this case)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on July 27, 2016, 09:45:17 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.
Title: Re: [EXE] OpenXcom Extended
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)
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on August 04, 2016, 08:27:30 am
Yankes,

I beg your pardon if I couldn't find it, but I was curious to know if their was an effect that could reduce TU % spent on firing, priming, throwing etc implemented.

In the same tact... is there effects to temporarily reduce  or increase firing and throwing accuracy, strength etc.

and

is there such a thing as negative fatal wounds? What I mean exactly is there a healing effect of regeneration where a soldier or monster could rapidly heal over time so long as they weren't killed outright?

and what about sight distance?

I had a few ideas about "combat drugs" or enemy attributes and was curious to know what was currently and a foreseeable possibility

Thanks!

-HH.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on August 04, 2016, 12:54:31 pm
Yankes, I have a problem with my X-Com Files mod: if I add battleType: 9 (like the Psi-Amp) to the alien deployment, it is ignored by the game and doesn't appear.
Meridian did some investigation and it appears that hostiles can carry battleType=9 items only in their hands (and if both are already full, it's just ignored):
 https://github.com/MeridianOXC/OpenXcom/blob/oxce3.0-plus-proto/src/Savegame/SavedBattleGame.cpp#L1300

It was apparently added by you on December 6th 2014:
 https://github.com/Yankes/OpenXcom/commit/2df6b7cc454583444d058c465634785a246e7683

Is there a legitimate reason for this? If no, can it be changed?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 04, 2016, 09:07:22 pm
Yankes,

I beg your pardon if I couldn't find it, but I was curious to know if their was an effect that could reduce TU % spent on firing, priming, throwing etc implemented.

In the same tact... is there effects to temporarily reduce  or increase firing and throwing accuracy, strength etc.

and

is there such a thing as negative fatal wounds? What I mean exactly is there a healing effect of regeneration where a soldier or monster could rapidly heal over time so long as they weren't killed outright?

and what about sight distance?

I had a few ideas about "combat drugs" or enemy attributes and was curious to know what was currently and a foreseeable possibility

Thanks!

-HH.
There now way to change item use cost right now. My biggest problem with that option is that it would easy cripple game logic when it change its value between first test for cost and moment when units are spend. This is of corse doable but simply cost too much to add this compared to what it give.

For changing accuracy or other bonuses, I have plans to add this in one way or another.

Regeneration is already added, day and night visibility range too.

In near future I will add new script capabilities that will allow adding buffs and debuffs.

Yankes, I have a problem with my X-Com Files mod: if I add battleType: 9 (like the Psi-Amp) to the alien deployment, it is ignored by the game and doesn't appear.
Meridian did some investigation and it appears that hostiles can carry battleType=9 items only in their hands (and if both are already full, it's just ignored):
 https://github.com/MeridianOXC/OpenXcom/blob/oxce3.0-plus-proto/src/Savegame/SavedBattleGame.cpp#L1300

It was apparently added by you on December 6th 2014:
 https://github.com/Yankes/OpenXcom/commit/2df6b7cc454583444d058c465634785a246e7683

Is there a legitimate reason for this? If no, can it be changed?
Because it would be dead weight and AI will not use it. If you are fine with it, this can be easy change.


Title: Re: [EXE] OpenXcom Extended
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 hands backpack.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on August 04, 2016, 10:09:33 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) and which you can then use manufacture to turn it into a proper psi-amp. Something like breaking the access codes or changing the interface (if it is carried by non-humans).
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Sputnik on August 10, 2016, 04:39:05 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...
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
Post by: Sputnik on August 10, 2016, 04:57:59 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.

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.
Title: Re: [EXE] OpenXcom Extended
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.

I downloaded the latest version of openxcomextended for Win from openxcom.com/mod/openxcom-extended.
After that I placed the .exe file to my OpenXcom folder, launched it and got the error message.
What did I do wrong?

Oh, now I see.. I need 2016-01-02 version of the OpenXcom to play OpenXcomEx... Thanks for pointing it out.
Needed data are in first post of this thread.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on August 11, 2016, 11:05:47 am
I sat down with Dioxine and we have compiled a list of features that we would like to see implemented the most. It is here:

https://docs.google.com/document/d/1pUZBoVKeZmfXUwIm4-FDRLx_fIISGFrp1131DLfyO40/edit?usp=sharing

Each feature contains a brief description of how it should work.

Many of these are old and already mentioned in places. Also, some of them are more sensible/easy than others. But all of them are there for a specific, practical reason, ie. there are actual plans for their use (in Piratez and X-Com Files).

Hopefully this will be of some use.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on August 11, 2016, 03:03:03 pm
EDIT: discussion moved here: https://openxcom.org/forum/index.php/topic,4830.0.html
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on August 11, 2016, 03:25:57 pm
Many thanks for the response.

If possible, I would like to recommend to move random treasure lists to a higher priority. Because it looks (to me, a layman) like a relatively simple job, and I know it'd be colossally beneficial. For example Piratez has many copies of the same ship with the only difference being some items laying on the floor; this is a very messy and time-consuming method.

And regarding custom factions in battles: considering the recent changes in the nightlies, which enable civilians to use guns, I guess handling it will be inevitable anyway. Better lay out some general objectives straight away than later.
(Possible implementations: multi-sided battles; savage animals which attack everybody.)
Title: Re: [EXE] OpenXcom Extended
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]
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on August 11, 2016, 05:40:13 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?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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:

https://docs.google.com/document/d/1pUZBoVKeZmfXUwIm4-FDRLx_fIISGFrp1131DLfyO40/edit?usp=sharing

Each feature contains a brief description of how it should work.

Many of these are old and already mentioned in places. Also, some of them are more sensible/easy than others. But all of them are there for a specific, practical reason, ie. there are actual plans for their use (in Piratez and X-Com Files).

Hopefully this will be of some use.
I appreciate grouping all proposal in one place, it will be helpful to finding what to do next.

btw "Global damageAlter per type" I will probably never do something that could alter permanently basic damage types. This will simply introduce conflicts between mods and made impractical to create different subtypes for one damage type. I would prefer adding option for multiple global alter types that could be shared between items or different mods. This could be reused too for custom smoke effects on tiles but this will be added in further future :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 17, 2016, 10:21:34 pm
You mean enabling global damageAlter per types, but only for custom types?
Yeah, it could work.
Right now I see this different, you create new "default" based on original and after that you use it as you fit.
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on August 18, 2016, 02:39:22 am
Quick question....

Is there definable and default inventory layouts for armor?

That is to say, if I had a guy with no armor on basically just a jumpsuit a soldier could have basically no space but his hands while a guy in crazy web gear or powered armor could have a ton more inventory space.

Is this possible? Pipe dream?

thanks!

Edited because of another question.

Is there an option for when being hit with a projectile weapon that doesn't penetrate armor to deal a fractional amount of stun damage instead?

-HH
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on August 18, 2016, 04:00:42 am
Piratez does have a hack that allows to vary inventories based on armors: You define the largest one as the inventory, then armors with smaller inventories get "black squares" items that cover up the slots that you don't want the armor to have. Sounds weird, maybe, but it works pretty well as far as the user is concerned.

Extended allows you to define armor penetration (ie ignore a % of armor) and to have multiple types of damage, so it might be possible. If not, I expect Yankes' answer will be: Scripts! ;)
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on August 18, 2016, 05:25:10 am
Cool,

Thanks Arthanor!

I'll have to pick through code/ script to figure it out... If I understand right you could have API (armor piercing incendiary), or HEIAP(High-explosive incendiary/armor-piercing) rounds. Fuck. Yeah.

I'll let yankes chime in.


Now to hope for an airstrike mod.

I'd love to designate a target with a laser and then x turns later it gets a paveway hammered on top of it... that would be sweet.

-HH
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on August 19, 2016, 02:36:42 pm
Yankes, when can we expect an update to newer nightlies?

It's not that I'm impatient, I would simply like to know, in order to plan my work better.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 19, 2016, 08:08:26 pm
Yankes, when can we expect an update to newer nightlies?

It's not that I'm impatient, I would simply like to know, in order to plan my work better.
I plan do two releases without it (2.3 and 2.4) and after that I will do 2.5 that primary focus will be merges (with nightly and some functionality from Meridian branch).
2.3 is now half done, I finished new lighting and now I start working on my version of custom visibility. After that I will add some small functionality requested here.
Hard to say how much exactly time will take to do 2.3 and 2.4, I guess that will take around 1 month to 2.5 and merge with nightly.
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on August 20, 2016, 03:42:41 am
Like a flashlight?

I wait with baited breath.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 20, 2016, 10:09:44 am
Like a flashlight?

I wait with baited breath.
I do not jest check if this will be possible (aka how many changes is needed to remove all glitches caused by this). But I still plan do this in 2.3.
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on August 20, 2016, 11:18:09 am
If you do I'll send you a fruit basket...

 ;D
Title: Re: [EXE] OpenXcom Extended
Post by: clownagent on August 20, 2016, 12:37:35 pm
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 20, 2016, 02:29:22 pm
A short question on scripts:

Is it possible with them to define secondary explosions?

Example: A demolition pack is lying around and hit by a grenade. The grenade then triggers the demolition pack to explode with its normal strength.
Right now you can't. In future it will be probably possible.
Title: Re: [EXE] OpenXcom Extended
Post by: SophiaThe3rd on August 28, 2016, 10:52:01 am
using the latest nightlies and oxce i seem to get a crash upon display of the cryssalid weapon icon from terror.png be it from debug mode or MC, other 3 terror units show correctly. bug?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 28, 2016, 10:57:14 am
lasted nights aren't supported. Correct data need by extended is in first post of this thread.
Title: Re: [EXE] OpenXcom Extended
Post by: SophiaThe3rd on August 28, 2016, 11:20:44 am
quoted from the first post:

Download available on mod site (require latest nightly):
https://www.openxcom.com/mod/openxcom-extended

perhaps just edit that line?
Great work though! I LOVE all the new fuctionality
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 28, 2016, 11:43:40 am
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.
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on August 28, 2016, 01:23:12 pm
I have a functionality request.

Auto shot weapons with long bursts increase their accuracy per shot after the first 3 shots by a few percentage points with each shot.

hopefully to simulate correcting or " walking" the fire onto a target.

so as an example you have an LMG with a 8 shot burst starting with a base accuracy of 25% and moving up ...all these numbers are hypothetical. so it looks like

25/25/25/28/31/34/37/40

thoughts?
Title: Re: [EXE] OpenXcom Extended
Post by: ohartenstein23 on August 28, 2016, 05:21:15 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.
Title: Re: [EXE] OpenXcom Extended
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.
-
Title: Re: [EXE] OpenXcom Extended
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?

What I did to get extended running ( and I'm going to produce a video  on this for tutorial purposes unless its not correct ) is:
- use a recent nightly,
- copy in the Data file from the first post,
- copy over original files from steam,
- copy in the latest OXCE executable.

The game launched OXCE when I did that, but I didn't try to check it for bugs (like chryssalid weapon bug).

Please let me know, Yankes, if those previous steps are incorrect.
-
You do not need current nightly only data folder from first post.
Simply extract "data.zip" to destination folder where you want have extended version.
Extract exe to that folder. Copy UFO or TFTD to correct subfolders and after that it should work.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 29, 2016, 02:09:18 am
If you have that big step then this weapon become frustrating in use. Not mentioning losing lot of ammo on first shoots.
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on August 29, 2016, 03:30:17 am
Are you trying to tell me that you don't like the idea because you think I am asking you to replace the existing auto shot?

That is not the case.

or

is it because of the hypothetical numbers I have listed? they are just a silly example to try to explain the idea.

perhaps I should explain the reasoning better and maybe I should of instead be asking for an additional new fire mode... let's call it long burst.

A light machine gun such as the SAW usually has a very large ammo capacity so wasting ammo is less of a frustration ingame.

With a weapon of this type the idea is a trade off of accuracy for volume of fire. The reason is for a slightly better reflection and viability of common real world tactics like suppressive fire and overwatch.

Suppressive fire, used to deny an enemy vision or mobility and over watch is to protect or warn men from threats they might not see.... I know you know this, but I'm writing it out for my own benefit.

Most of this will be accomplished already through improvements I belive are planned on existing auto fire.

However, why I am asking for an incremental increase in accuracy is that when you shoot a machinegun; the results of your fire can give clues on where to aim to hit what you want.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on August 29, 2016, 07:50:30 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?


Title: Re: [EXE] OpenXcom Extended
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 :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Which is a bit of a difference.
Then this would be equal comparing two weapons that have 50 and 30 accuracy.
I ask about that have similar performance.

Expected number of landed hits:
1.5 for either configuration

Chance to fail to land a hit:
with 10/20/30/40/50: 0.9*0.8*0.7*0.6*0.5 = 0.1512 ~ 15%
with 30/30/30/30/30: 0.7^5 = 0.16807 ~ 17%

Chance to land all shots:
with 10/20/30/40/50: 0.1*0.2*0.3*0.4*0.5 = 0.0012 ~ 0.12%
with 30/30/30/30/30: 0.3^5 = 0.00243 ~ 0.24%

Alright, it's not that different, but it is different. The results will also vary for other numbers of hits, but those are more complicated and I'm at work. The point is, although both weapons have the same expected number of shots, one is more reliable to land a hit, while the other is more likely to land many hits. We tend to just consider averages (average outcome is the same, everything is the same), but there's more to distributions of numbers than that.
Fully agree, there are different but is this difference big enough to be something more that some kind of flavor?

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.
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on August 29, 2016, 10:51:10 pm
Yes, I agree that the difference doesn't affect gameplay much, but over 10-20 shots (not uncommon in XPiratez), seeing the last few shots always hit instead of everything being scattered equally could be more satisfying. Also seeing rifles with multiple shots deteriorate as the autoshot goes would be funny. It does contribute to the experience even if it doesn't affect the stats much. Even better if somehow hit location of the previous bullet can be factored in, maybe reusing some code of the shotgun fix.

I also agree that a deeper implementation would be much more interesting. It would help further diversifying if the a, b, c coefficients I suggested could themselves depend on strength, firing accuracy and setup (flying makes recoil worse as you have nothing to stabilize against, kneeling makes it better as you are braced). But constant coefficients are a first (baby) step that already enables a little bit of something (and might be able to placate the request, as I have seen it multiple times already).

As I think that changes of distribution do affect player experience, I just wanted to chime in and support the idea. I fully understand why it isn't (and shouldn't) be a priority. But it shouldn't be entirely dismissed either. As Meridian said, for 5.0! ;)
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on August 29, 2016, 11:38:15 pm

Thank you,

to you both.
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on September 06, 2016, 06:03:12 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, 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
Title: Re: [EXE] OpenXcom Extended
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  ;)
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on September 06, 2016, 06:46:08 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, smoke that is rapid stunning, smoke that causes panic/berserk state, smoke that robs TUs, more smoke density or visibility states, and

So basically... trick smoke and improved smoke behavior.


The reason I am asking is because of some of the great possibilities that are forthcoming with features like armed civilians and I feel that more types of smoke could lead to some cool stuff.

So we can have things like a SWAT cop throw a CS grenade into a building and smoke out sectoids or We can have alien enemies that use poison gas a la Signs.

We could better simulate toxic smoke or fumes from burning chemical barrels.

There would be a whole range of things that would be wonderful and add depth to the battlefield.


Thoughts?

-HH
Other people ask for this too. Right now its on my "far" todo list (far as in far future :>).
Title: Re: [EXE] OpenXcom Extended
Post by: CanadianBeaver on September 06, 2016, 07:16:45 pm
I think the Craft Screen in OpenXcom Nightly is much better than in OXCE. What do you think?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: CanadianBeaver on September 06, 2016, 08:54:15 pm
Wrong order in UFOpedia
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on September 06, 2016, 09:11:33 pm
Erhm.. ufopaedia articles have their own listOrder to sort them. It is in no way related to the listOrder of the baseFacility. Have a look here (https://www.ufopaedia.org/index.php/Ruleset_List_Order_(OpenXcom)#Ufopaedia).
Title: Re: [EXE] OpenXcom Extended
Post by: CanadianBeaver on September 06, 2016, 09:22:47 pm
How I see, the listOrder in the facilities is related to UFOpedia articles. Look on the ordered and unordered (default) screens.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on September 06, 2016, 09:39:33 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?)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: clownagent on September 29, 2016, 03:11:13 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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on September 29, 2016, 07:17:38 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.
Doable, but it will need wait because my queue is full right now.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: HelmetHair on September 30, 2016, 04:12:34 am
Yankes,

would you be willing to share your feature queue? I'm having a shit week and need something to smile at.

-HH
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on September 30, 2016, 06:54:55 pm
Yankes,

would you be willing to share your feature queue? I'm having a shit week and need something to smile at.

-HH
This week releasing version 3.3 with:
new lighting (next week will I will probably spend on optimization of this based of people feedback)
scripted visibility
option for reserving more space for mod in common sets like HandOb

I had plans to add some other small features but because other take me too much time to finish, I push it to next release.
This was global throw properties and directional lights/flashlights.
In 3.4 I plan add scripts that will be able directly change state of unit (it will be call at end of each turn or when unit get hit).
After that in 3.5 I would like to merge with nightly and cherry pick commits some from Meridian branch.

Hard to say when 3.4 and 3.5 will be ready, usually my prediction miss a lot.

Good idea.
Is the maxrange always a fixed value, or can I define it as strength dependent?
Something like:
maxRange: 0.5* strength
Right now its fixed value.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on September 30, 2016, 07:01:35 pm
Great news, Yankes!

Will 3.3 include newer nightlies?

Is the maxrange always a fixed value, or can I define it as strength dependent?

AFAIK it's not possible yet. Unless Yankes could write a script or something.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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!
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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?).

I'd like to review all my commits, make a new branch and prepare new commits worthy picking and maybe even going to vanilla.
The cleanup would include:
- full translation support
- full interface support (i.e. separate ruleset for colors and similar stuff on new GUIs)
- full TFTD suppport
- merged multiple commits together (like original commits + its bugfixes)
- reorder commits a bit for easier cherry-picking
- split some commits (into OXC-compatible part and OXCE-extension)
- etc.

Basically I'd like to make a branch, which wouldn't be called "prototype" anymore... but I need OXCE 3.5 (with latest nightlies) for this work... for which I am waiting patiently, no rush.
Ok, no problem. I think if you wait for 3.5 I will skip thing I want do in 3.4 and start right now with 3.5 (I could use 3.4 number for that but I prefer "round" version number for that milestone :D).
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 01, 2016, 02:11:31 am
Ok new version 3.3 is ready:

New light system.
Option for reserving more space for mod in common surface/sound sets.
Visibility scripts that determine visibility of targets.


I mostly interested in how my new light system is performing on peoples machines.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on October 01, 2016, 12:29:47 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).

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.
Title: Re: [EXE] OpenXcom Extended
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).

I will need to revert, reimplement an retest night vision, heat vision and psi vision.

On the bright side, I have cherry-picked the option to increase modOffset for mods, so at least that can be implemented in XFiles/XPiratez and tested.
Right, I probably need cheery pick your visibility changes as promised that my will be compatible with yours.
Any thing else was conflicted?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 02, 2016, 05:24:37 pm
Small recap what is possible with new visibility scripts:
a) Some unit can be visible only to some other units, something like A can see B, C can see D but A cant see D and C cant see B.
b) Items in hands can affect visibility of units, you can add NV googles that need be held in hands to allow see in darkens or masking device that will cloaking you.
c) Effectiveness of visibility is stored as integer value. Greater than zero mean that other unit is visible. This allow gun scope that add value to that number increasing effective sight radius of unit. Alternative you can subtract to recreate some camouflage. As IR visibility should not be affected by scopes or normal camouflage, I added option for distinguish between different visibility modes. Normal visibility (in visible light lengths) is defined by empty value `null` other types can be defined by new tag in `BattleUnitVisibility`.
d) You have access to raw data of smoke and fire density, this allow you to change how smoke affect visibility or allow fire to prevent use of IR.
e) You can add penalty for NV googles if target is in bright spot, or simply add bonus/penates based on relative lighting level of tiles where units stand (current and target) to simulate that you can't see thing in shadow.
f) All units stats can contribute to visibility. You can made cloaking device that will fall or reduce it effectiveness when unit lose hp (or current TU).

Things I would like to add in some future:
a) Visibility that ignore walls.
b) 360 degree visibility (right now it sill use old FOV cone).
c) Drawing of unit will get info how other units see it, e.g. "Is this unit normally visible?", "I can see it only using IR or Psi?".
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on October 02, 2016, 09:03:30 pm
Yankes, please consider below features:

1) object like crafts or bases displayed on geoscape can have custom sprite, also size other then 5x5 pixels. Also different one in case hyperwave decoder is used (unknown ship / known ship), maybe even different sprite based on current ship status.
2) crafts can have optional weight limit, that could limit how much items weight can carry. This is opossite to number of items in original game. This could lilmit items that can be take for battle but also items salvaged from battle (like elerium).
3) damage inflicted to unit can be displayed as number on the top of the unit (like in many RTS games)
4) base defence buildings have N shots not just one. This could be used for cannons that fire many Times with minimal hit Chance.
5) damage taken to alien craft durig base assult should define number of aliens that will die in turn 1 of the battle.
6) alien intelligence can be splitted into two variables:

Alien will remember any soldier he spots in his field off view for N turns where N = intelligence, other aliens are not aware of these soldiers
Alien will make other aliens remember any soldier he spots in his field of view for K turns where K = group intelligence (new alien stat)
Alien will pass his memory of soldiers to any other alien that is with his field of view for M turns, where M = telepathy (new alien stat, optional, very complex to implement but could be helpfull to create chain of memory strategy for aliens, so xcom can pass grenades and aliens could pass positions of xcom soldiers that way)

So IQ =  5 and Group IQ = 1, means that alien will remember spotted soldier for 5 turns + he will make other aliens remember them for additional 1 turn

Using this engine we could implement standard behavior from X-COM but also bring much more for mods.

More here https://github.com/Bladum/OpenXcom/commits/master

Thanks
Tom
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 03, 2016, 07:11:01 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.
I will look on this too. In my case half work is done because I write part of it.

btw did you play with my new lighting? Do you have any feedback about how it work or its performance?
Title: Re: [EXE] OpenXcom Extended
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().



Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 04, 2016, 09:12:32 am
Yankes, please consider below features:

1) object like crafts or bases displayed on geoscape can have custom sprite, also size other then 5x5 pixels. Also different one in case hyperwave decoder is used (unknown ship / known ship), maybe even different sprite based on current ship status.
2) crafts can have optional weight limit, that could limit how much items weight can carry. This is opossite to number of items in original game. This could lilmit items that can be take for battle but also items salvaged from battle (like elerium).
3) damage inflicted to unit can be displayed as number on the top of the unit (like in many RTS games)
4) base defence buildings have N shots not just one. This could be used for cannons that fire many Times with minimal hit Chance.
5) damage taken to alien craft durig base assult should define number of aliens that will die in turn 1 of the battle.
6) alien intelligence can be splitted into two variables:

Alien will remember any soldier he spots in his field off view for N turns where N = intelligence, other aliens are not aware of these soldiers
Alien will make other aliens remember any soldier he spots in his field of view for K turns where K = group intelligence (new alien stat)
Alien will pass his memory of soldiers to any other alien that is with his field of view for M turns, where M = telepathy (new alien stat, optional, very complex to implement but could be helpfull to create chain of memory strategy for aliens, so xcom can pass grenades and aliens could pass positions of xcom soldiers that way)

So IQ =  5 and Group IQ = 1, means that alien will remember spotted soldier for 5 turns + he will make other aliens remember them for additional 1 turn

Using this engine we could implement standard behavior from X-COM but also bring much more for mods.

More here https://github.com/Bladum/OpenXcom/commits/master

Thanks
Tom
1) Maybe
2) This probably will cause lot of problems when you reach limit after mission. Without special UI it will not work and I prefer not change UI.
3) Again this is UI change that I avoid.
4) Maybe
5) This could be useful
6) Probably too complex for small grain, difference to current behavior will be probably not visible for player.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.

Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on October 05, 2016, 11:17:17 am
@Yankes: There has been a change in map rendering from 3.2 to 3.3, which I don't fully understand... can you explain why did it change?

Or, at least, where should I put the night vision re-shade functionality within the getWallShade() method... on individual components (if so, which ones exactly) or at the end on the return value?

Comparison attached. Hopefully understandable enough.

PS: there are together 4 such places with the new getWallShade() method.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 05, 2016, 07:03:44 pm
This was added to allow light "bleed" through doors. Without this you will never see doors if you approach them from behind.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on October 06, 2016, 05:27:07 pm
OK, I have finished merging yesterday.
Looks quite good.

I tried doing some performance measurements, but doing it properly would take many different scenarios and a lot of time.

Just as example, I measured:
1. the drawTerrain() method
2. and a walking animation using full TUs

Results were in average about 10% worse on v3.3 compared to v3.2.

drawTerrain(): 10 measurements
- v3.2: times between 2900 and 4000 micro seconds... averaged ~3350 micro seconds
- v3.3: times between 3300 and 5800 micro seconds... averaged ~3700 micro seconds

But given the big spread, it might also be just a measurement error :(

walking animation: 5 measurements, with much smaller spread, so probably a good/reliable test
- v3.2: times between 2000 and 2200 milli seconds... averaged ~2125 milli seconds
- v3.3: times between 2350 and 2650 milli seconds... averaged ~2475 milli seconds

This was a much more consistent test, so I guess I can safely say that on this particular scene (see attachment) with these particular settings on this particular PC (high end from 2016)... v3.3 is about 10% slower overall.
I don't know how much of the whole walking animation can be credited to FOV-related stuff. If most of it, then the degradation of 10% is probably acceptable; if only a fraction of it, then the FOV-related stuff might have a much bigger degradation, which would not be desirable... but I don't know how to effectively measure only FOV-related part.

Finally, the test should be done on slower PCs; on several different (complicated) scenes and with several different video settings too I guess.
I however don't have time for it... so I'll try to play real campaign with v3.3 and if I see something slower than usual, I'll make a save and try the same with v3.2 to see if there's any noticeable difference.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 06, 2016, 07:11:42 pm
`drawTerrain` is not bottleneck, biggest offender should be `calculateLighting`. I attach save on with I test performance degradation.
Opening and closing doors need recompiling shadows for every layer. Adding lot of fire that is independent light source made it even slower.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on October 06, 2016, 07:27:45 pm
Yeah, I did drawTerrain() test mostly because of night vision... which also seems OK.

I'll try your save later too... and I have a quite nice save from Siberia Mission in PirateZ too (with lots of doors and tons of fire), I'll try that too.
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on October 09, 2016, 09:20:21 am
Yankes, another ideas

1) if country is leaving x-com due to pact it may lose ability to research / purchase / manufacture items or disable specific missions
2) item may have option to be fully 2 handed, which means no other item can be even put into another hand, not just some limitation to use items. Therefore you cannot use flare and 2handed heavy weapons at the same time.
3) can we limit items to be put into specific inventory slot ? for example item helmet can be put only into helmet type inventory slot.
4) time to kneel depends on armour type. I cannot imagine no armour cost 4 points and power armour too to kneel.
5) ability to rescue country from under alien pact somehow. If alien pact creates alien base in country, then destroying this base could bring country to x-com again. How exactly this could be done its up to you, either by script or by flag to mission (global effect on geoscape after battle is won).
6) limit max level of stat for soldier based on their initial stats. Now all soldiers have random initial stats (20-40) but common max stat (60). Would be nice to have either max stat level (60) or max stat change (+20) from their initial level.
7) ability to set intelligence for soldiers that would define their own speed of gaining experience on the top of global parameter. This does not have to be shown on the UI but could be also randomized just like any other stat. Some soldier types could have 80-120% but others 200% or 50% of base rate.
8) define how many slots specific craft takes during interception. At the moment there are max 4 crafts at the same time, would be nice to set this value to N and then define weight for each craft. Some smaller crafts could take 0.5 space when others could take 2 etc...Also max number of crafts could be based on UFO size.

PS: new lightning system works fine for me regarding performance. I haven't noticed any perfo issues.

Regards
Tom
Title: Re: [EXE] OpenXcom Extended
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!
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 09, 2016, 02:08:35 pm
Solarius Scorch have in 97% same answer as me :)

Yankes, another ideas

1) if country is leaving x-com due to pact it may lose ability to research / purchase / manufacture items or disable specific missions
[...]
5) ability to rescue country from under alien pact somehow. If alien pact creates alien base in country, then destroying this base could bring country to x-com again. How exactly this could be done its up to you, either by script or by flag to mission (global effect on geoscape after battle is won).
This could be done as part of bigger functionality added is some future. This is similar to overriding game over conditions, as standalone feature is not useful or even bad for game but as part off bigger system I could shine. Image you start only with one country and need conquer/convince other to join you cause.
End game then could be that all countries join XCOM :)

This would need wait until I finish adding scripts to battlescape, after that I could work on geoscape.

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.
[...]
6) limit max level of stat for soldier based on their initial stats. Now all soldiers have random initial stats (20-40) but common max stat (60). Would be nice to have either max stat level (60) or max stat change (+20) from their initial level.
This more like tweaking that new gameplay mechanic.
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on October 09, 2016, 07:57:28 pm
After few days of extensive tests, I like the 3.3. Even if someone isn't into scripting, the new light effects alone are worth upgrading. I found no bugs either. Highly reccomended.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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".
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on October 11, 2016, 03:09:19 am
Maybe not this one, but cases can be made for slower and faster learning soldier types. Whereas it's robots that have a longer development cycle than humans learn (indeed, an improvement on all robots should be as good for all robots of the same series, a process better represented by a patch/upgrade mechanic in the workshop than by battlefield learning).

I could also see a limit of craft number for interceptions, because airspace is not unlimited even if it is big. For something really fast and maneuverable (so changing directions a lot), trying to have many crafts following would expose pilots to errors and collisions, a situation best avoided by: reducing/capping the number of crafts trailing to a safe number.

But the kneeling one shows a misunderstanding of the TU system. Firing has a relative cost: it's the same % of your turn and it is the reference for an action in the game. An armor that gives more TUs means a soldier is moving/kneeling faster, an armor that removes TUs means that you move/kneel slower. Tweaking kneel costs, door opening cost or moving cost is meaningless.
Title: Re: [EXE] OpenXcom Extended
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).
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on October 11, 2016, 02:10:16 pm
heresy time :)

i am just throwing ideas, maybe you will use it one way or another.

1) I assume changing armour during battle is very big change and wont be able to implement. It could be big inventory slot of type 3 (armour) and then just drag and drop armour just like any other item.
2) display armour weight somewhere on the soldier inventory screen. Now to check what is armour weight the only way is to remove all inventory / items from soldier. it may be also displayed as a "mouse over" event when mouse cursor is over the soldier image then item description is shown "Personal armour [12]" just like any other item.
3) any easier way to unload weapon on the soldier inventory screen (like RMB on weapon to auto unload). If clicked on ground then unload would be done on ground. If clicked on inventory then it would be added to same place if applicable, if not then to hand, if not then to the ground.
4) action on UI to reload weapon automatically, so you can choose snap / auto / aim / throw / reload option now (commit here https://github.com/Bladum/OpenXcom/commit/53b1b1fb03479759c7c0877a5afa859d9bc90851)
5) display more complex item action information box once choose item action during battle (commit https://github.com/Bladum/OpenXcom/commit/53b1b1fb03479759c7c0877a5afa859d9bc90851), it display smaller font with more detailed information about action performed. Also with smaller font more actions could be added in the future.

Sorry for no screens for UI changes but i made commits some time ago.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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!
Title: Re: [EXE] OpenXcom Extended
Post by: bladum on October 11, 2016, 04:49:46 pm
great Solar that you like at least one thing :)

few another ideas

1) aiming level of details that are displayed when soldier is aiming at the enemy

level 0 - reduced vision, no percentage chance displayed
level 1 - current vision, percentage chance displayed
level 2 - improved vision, percentage chance to hit + potential damage (for wall ? object etc)
level 3 - total vision, chance to hit + potential damage + current life or weakness etc

This similar to perk system in Fallout.

Level may be related to either skill of soldier (accuracy) or his promotion level or equipment (custom tags) or race / soldier / armour type.

2) some items are not designed to be thrown at all. Therefore either it should be modifier to weight or to throwing accuracy. Grenade 3 (3) but high explosive is 6 (12) effective for throwing so it rather should be . It may also be done as a flag, not designed for throwing and changing weight for throwing by 50% or 100%.

3) in closed rooms when ceiling is low, there is problem to throw far away as item is being blocked by ceiling. Possible to implement alternative way of throwing working similar like bullet but with shorter range ?

4) ability to recover unit from battle based from enemy or neutral unit that survived battle (stunned or alive). It would generate x-com soldier (based on one of selected types in "soldier") inside transporter based on data defined in unit class itself. It would be useful for rescue mission or to get single / unique soldiers.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 12, 2016, 11:31:32 pm
Not yet, I will soon start on merging recent changes from master and it will be added.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 16, 2016, 10:52:18 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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.

Did you mean other doors in this UFO or other doors in other UFOs/buildings?
In this UFO (very large battleship), all doors to the east and south are not visible.
In other buildings.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on October 17, 2016, 10:07:14 pm
In other buildings.

Yes, happens everywhere.
Two examples with test saves attached.
Title: Re: [EXE] OpenXcom Extended
Post by: Starving Poet on October 22, 2016, 05:48:02 am
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 22, 2016, 01:30:56 pm
Yes, happens everywhere.
Two examples with test saves attached.
I find cause of bug, `getWallShade` -> `isDiscovered` check wrong part. I will release fix in this week (with another one that fix corpse bug).

While I was going through my TFTD playthrough, I found myself in the situation where I had to buy a Triton for every base just so I could easily equip weapons and armor on my troops who only existed to rebuff retaliations.  It felt like an awkward, unneccessary step.  Since there is the option to remove the arbitrary item limits on crafts, could there be a possibility to allow the crew equipment screen without a craft?  Just allowing soldier equips straight from base stores would be such a phenomenal time saver in the long run.
This more fit Meridian branch when he add lot of UI improvements.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
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#msg72679
Or a different one?
Exactly this, `part` should be less by 1.
Title: Re: [EXE] OpenXcom Extended
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*
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on October 22, 2016, 08:00:29 pm
*sandwich!*
Title: Re: [EXE] OpenXcom Extended
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).
Title: Re: [EXE] OpenXcom Extended
Post by: Starving Poet on October 24, 2016, 02:32:26 am
That may or may not affect my current mission fail rate  ;)
Title: Re: [EXE] OpenXcom Extended
Post by: Ridаn on October 24, 2016, 02:08:26 pm
I have a heretical proposal: a mod defined option for shared global vault space for all the loot and weapon items.
Soldiers/tanks and interceptors/transports would still have to be transfered, but all the other stuff can be accessed from any Base at any time, be it for manufacture, selling or loading into a craft.
Title: Re: [EXE] OpenXcom Extended
Post by: The_Funktasm on October 24, 2016, 03:01:13 pm
I'm absolutely certain I'm an idiot right now...

That out of the way, how exactly does a potential user acquire this in an already usable file or installer? I've found the compilable code, and tried and failed to DL it on openxcom.com.

Thanks in advance, but please take it a bit easy on me. My connection sucks where I live, so I can't look as well for myself as I would like to.


And yes, I checked the first page.
Title: Re: [EXE] OpenXcom Extended
Post by: ohartenstein23 on October 24, 2016, 03:24:28 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)
Title: Re: [EXE] OpenXcom Extended
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...
Title: Re: [EXE] OpenXcom Extended
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.

Though unfortunately now that I've tried, it will not run. I tried it with the version I had been running the game with, the most recent nightly, and the one before that one. Unfortunately the link mostly had a changelog, and no instructions of any sort. Even the file was just an exe in a zip file. So I'm not sure what to do at this point...
Because I did couple of big project (scripts), and now I lag couple of moths behind nightly. This mean currently is not compatible with recent nightly.
From first post:
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on October 27, 2016, 05:27:12 pm
in SavedBattleGame.cpp, _alienCustomDeploy and _alienCustomMission are loaded, but not saved: https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/SavedBattleGame.cpp#L119

a/ is saving missing?
b/ is loading not necessary and can be removed?
c/ have I missed something?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on October 27, 2016, 07:20:48 pm
a)
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on November 06, 2016, 07:29:23 pm
I think we may have found a rather critical issue in OXCE 3.3: https://openxcom.org/forum/index.php/topic,4822.msg73841.html#msg73841

Please have a look if what I say there is right or not.
Title: Re: [EXE] OpenXcom Extended
Post by: RSSwizard on November 09, 2016, 09:32:28 pm
Dunno if this is as much a feature request as it is a bug, but I noticed this while playing x-piratez and since there wasnt an option for turning it off I must assume its the engine:

If a soldier sees an alien (or more than one) it stops them in place.
But it does it more than just the 1st time the alien has been seen, it does it every time somebody sees them (individually) for the first time. Even though the alien has already been seen by the player's forces.

Now I understand its worth the caution but if the critter has already acted, or has melee only, or if they've got their back turned... and especially if there are a BUNCH of aliens (like 4, 6, or even 10) then I have to keep CLICKING over and over and over again for every soldier I want to move through spotting territory. I even end up mis-clicking and moving them somewhere I dont want to because I just get so frustrated with it.

*I* as the player already know the aliens are there, I know where they are because of the indicator. Its good to stop the soldier when they spot one ... but then its up to me whether ive got the brains to move my soldiers through beaten zones. The soldiers themselves dont need to keep stopping over and over again.

Vanilla does not have this feature, it notifies and stops your soldier when an alien has been seen for the first time that round (it can even eat up some time units by stopping them), but after that nobody else is going to freeze in their tracks.

In X-Pirates for example all my soldiers have melee weapons usually, there may be like 4 or 6 enemies in plain view but I have to rush up to get to cover close to them and that means moving the soldiers through seeing all of those guys, over and over and over again.

This is like a Nag Screen on a dos game.

This is Artificial Difficulty and it takes away from the enjoyability of the game.

Ive tried to hold down the Alt key, the Ctrl key, the Shift key while moving to do a "forced move" like other tactical games have but it doesnt bypass the behavior. Its infuriating.

I understand its a good design/safety feature, but pleeeeeease provide an option to turn it OFFF


EDIT:
The other thing id like an option to turn off is the "pausing" in motion between units moving from one tile to another. Vanilla xcom didnt do this, it just started moving them immediately to the new tile as soon as they reached a tile, the movement speed just dictated how quickly they moved between tiles.

Again just an on/off option, not to remove the feature because I think it is useful, but it feels like the game is stuttering even if it isnt.
Title: Re: [EXE] OpenXcom Extended
Post by: ohartenstein23 on November 09, 2016, 09:40:57 pm
OXCE+ has it set that running (CTRL) or holding SHIFT does ignore sighting new enemies, what you might be experiencing is a reaction check on a range-limited weapon or an arcing weapon that can't actually make the shot.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 10, 2016, 12:46:41 am
EDIT:
The other thing id like an option to turn off is the "pausing" in motion between units moving from one tile to another. Vanilla xcom didnt do this, it just started moving them immediately to the new tile as soon as they reached a tile, the movement speed just dictated how quickly they moved between tiles.

Again just an on/off option, not to remove the feature because I think it is useful, but it feels like the game is stuttering even if it isnt.
As Meridian said this is performance problem, this is always happening? If you run normal XCOM using piratez exe its works same? What processor you have in your comp?
Stian put lot of work to speed up this but there is some limitation what you could do. If problem is with weak hardware then is not many things to fix without rewriting big parts of engine.
Title: Re: [EXE] OpenXcom Extended
Post by: RSSwizard on November 11, 2016, 03:29:43 am
Based on what you guys said that sounds like it might be the issue. Ive noticed some enemies turn while im moving and it stops then, but they're not firing anything just turning (the enemies have pistols I think, ive rarely run into any enemies in piratez that throw things, even ratmen with bows are able to fire a long distance).

Ive got a netbook so performance *might* be an issue. It takes over a minute for the program to load with the mod (and normal openxcom takes about 30 seconds to load).

I also have no video card, OpenGL is locked at v1.4 so I cant use shaders. But I dont try, so no biggie (that locks OXC up so bad I have to delete the config otherwise it never runs).

Unrelated: is there a wiki or documentation of the new ruleset functions for OXCE+? Its nice to look through piratez' ruleset for how some things were done but I might be missing cool stuff (somebody mentioned terrainDamage multiplier though its probably not implemented yet).
Title: Re: [EXE] OpenXcom Extended
Post by: Arthanor on November 11, 2016, 04:20:43 am
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.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
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.

For example: Chryssalid hits, main attack does normal damage but has a linked zombification weapon. If the attack does any damage (health) to the character, they get hit with the linked weapon and wouldnt you know, they turn into a zombie. But unless they can be hurt (stung) it doesnt do anything because the linked attack isnt triggered.

Same idea for a Harpoon Tranquilizer, can make it do 20 AP but the 50 Stun is a linked attack. If the target takes so much as 1 health damage from the dart they take the 50 stun damage roll (a kind modder can still give the armor some effectiveness against it, maybe 0.2, that way the dart gets stuck in but not deep enough to fully inject).
This is too on my TODO list.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 13, 2016, 01:58:03 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
Title: Re: [EXE] OpenXcom Extended
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. ;)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 13, 2016, 02:23:25 am
What are the incompatibilities? What has been changed? Do you happen to have any comprehensible log? :)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 13, 2016, 03:37:03 am
Thank you! I'll be very grateful, and probably not only I :)
Title: Re: [EXE] OpenXcom Extended
Post by: RSSwizard on November 13, 2016, 04:23:53 am
w h o a a a

After posting it I check changes in basic rulesets, and probably it wont b so bad. One that I find that is incompatible is waypoint weapons (instead of bool is number).
Tomorrow I will prepare something like that.

does that mean that we dont get # of waypoints anymore, or did we go to a number rather than a yes/no?  (vanilla limit was 9 so this is not a problem if the boolean was removed, can just set it to 9 if desired)
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 13, 2016, 04:32:13 am
It means that if you don't change your ruleset, it will crash, since it'll look for integer and find a boolean.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
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)
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 13, 2016, 04:21:06 pm
I filter out some less interesting commits. But still over 200 lines.
Title: Re: [EXE] OpenXcom Extended
Post by: Solarius Scorch on November 13, 2016, 05:01:56 pm
Thanks, an interesting read.

Is there anything besides Blaster Launcher waypoints which absolutely needs to be changed to work properly?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 13, 2016, 06:40:51 pm
Thanks, an interesting read.

Is there anything besides Blaster Launcher waypoints which absolutely needs to be changed to work properly?
Hard to say, I added changes form ruleset used by basic ufo. aside form `waypoints` the `destroyItem` was added that change behavior of research.
Title: Re: [EXE] OpenXcom Extended
Post by: clownagent on November 17, 2016, 09:32:08 pm
I have a feature suggestion:

Add a tile property that reduces sight distance, but does not block walking or shooting through. With this a modder could add tiles that represent fog (on part of map), sand storms (on part of map), waterfalls, thin curtains, illusionary walls, etc... for more interesting maps. 
 

I think there are several possibilities to implement this, but I cannot judge how much work it will be:

1. There is LOS mcd (no 31), which can be switched to block line of sight to terrain but it does not block line of sight to units. Change the behavior that it also blocks sight to units (not sure if this would change vanilla gameplay???).

2. Add completely new mcd value which can be added to a tile via ruleset with 'mcdpatch'. The new mcdvalue could be an integer that, if switched to non-zero, reduces sight range similar to smoke.

3. Make it possible that units can shoot through very 'soft' tiles. That means tiles with sight blocking LOFT,but very small damage resistance (zero or less?) do not block projectiles and melee attacks.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 18, 2016, 12:54:21 am
I have a feature suggestion:

Add a tile property that reduces sight distance, but does not block walking or shooting through. With this a modder could add tiles that represent fog (on part of map), sand storms (on part of map), waterfalls, thin curtains, illusionary walls, etc... for more interesting maps. 
 

I think there are several possibilities to implement this, but I cannot judge how much work it will be:

1. There is LOS mcd (no 31), which can be switched to block line of sight to terrain but it does not block line of sight to units. Change the behavior that it also blocks sight to units (not sure if this would change vanilla gameplay???).

2. Add completely new mcd value which can be added to a tile via ruleset with 'mcdpatch'. The new mcdvalue could be an integer that, if switched to non-zero, reduces sight range similar to smoke.

3. Make it possible that units can shoot through very 'soft' tiles. That means tiles with sight blocking LOFT,but very small damage resistance (zero or less?) do not block projectiles and melee attacks.
In some future I plans add something like that.
Title: Re: [EXE] OpenXcom Extended
Post by: Ethereal on November 19, 2016, 12:51:21 pm
I do not know what you've done, but the problem with the latest version. In the version of September 2015, everything works fine. Change to the last - not even included in the menu. Buggy on missionScripts line. I do not know that there can fail, because under the old version of the game still works fine.

Can the same be done so that the original logic is not much changed, or changed, but at the request?

Не знаю, что вы сделали, но с последней версией проблемы. В версии сентября 2015 года, всё работает отлично. Меняю на последнюю - даже в меню не входит. Глючит по линии missionScripts. Не знаю, что там может глючить, ибо при старой версии в игре всё работает отлично.

Можно-же было сделать так, что бы логика оригинала не сильно менялась, или менялась, но по желанию?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 19, 2016, 01:11:22 pm
You do not updated data folder.
Title: Re: [EXE] OpenXcom Extended
Post by: clownagent on November 20, 2016, 05:22:32 pm
I tried to use the

fuseTimerType: 0
and
fuseTimerType: 2

options on a normal grenade to restrict the timing posiibilities, but the grenade bahavior was not changed.

How do I get this working?

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.
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 20, 2016, 05:36:35 pm
I tried to use the

fuseTimerType: 0
and
fuseTimerType: 2

options on a normal grenade to restrict the timing posiibilities, but the grenade bahavior was not changed.

How do I get this working?
I made bug in documentation, proper name is: "fuseType".
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 20, 2016, 06:12:06 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?
"-1" is default behavior. "-2" is instant grenade.
And in some future I will add option for grenades exploding in inventory.
Title: Re: [EXE] OpenXcom Extended
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
Title: Re: [EXE] OpenXcom Extended
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, указать эти значения для урона по местности?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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)
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on November 24, 2016, 11:00:12 pm
Bugreport for OXCE 3.5:

This will CTD for some missions (e.g. TFTD ship terror):
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/AlienMission.cpp#L185

PirateZ has lots of such missions...

In vanilla, this is taken care of separately:
https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/AlienMission.cpp#L186
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 24, 2016, 11:25:02 pm
Bugreport for OXCE 3.5:

This will CTD for some missions (e.g. TFTD ship terror):
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/AlienMission.cpp#L185

PirateZ has lots of such missions...

In vanilla, this is taken care of separately:
https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/AlienMission.cpp#L186
Fix is remove `true` from `getDeployment`. This option is for early caching bugs with missing data. In that case I wrongly assume that this data was required.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on November 26, 2016, 11:44:01 am
Is there an easy way to turn on the vanilla lighting?
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.

I gave it a try in the last 2 months, playing piratez, and I like it even less than at the beginning. It's unnecessary and visually disturbing (for me). I guess some people like it, that's why I'm asking for an option, but I will definitely turn it off for me.

Also, now that we are back on nightlies, I would like to play some vanilla mods using oxce (e.g. Area51), which are not optimized for this kind of lighting... and throwing flares absolutely everywhere is a total fun-killer.
Ok, I will add option for that.
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on November 26, 2016, 03:16:02 pm
Thanks!

Also, testing 3.5, I found some funky unit animation.... not sure if it's because of OXC or OXCE, but it doesn't do this in 3.3.

Example here: https://youtu.be/vEJZsesymKA

Don't know how to describe it, hopefully it's visible enough.

EDIT: seems to be an issue with 2x2 units... tanks suffer similar effects
Title: Re: [EXE] OpenXcom Extended
Post by: Yankes on November 26, 2016, 03:25:50 pm
I will look on this too
Title: Re: [EXE] OpenXcom Extended
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?
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
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.
Title: Re: [EXE] OpenXcom Extended
Post by: Dioxine on November 26, 2016, 03:54:58 pm
The old lighting system literally looks like shit compared to the new one, it is also very unnatural (drop a flare on the roof, get the whole building illuminated; and, when you want to hide, the only option is to run, instead of simply stepping into a dark corner), but to each their own... What's need to be done is some ironing out of the new system (light getting trapped in some light-generating objects, only illuminating the floor but not the object or surroundings).
Title: Re: [EXE] OpenXcom Extended
Post by: Meridian on November 26, 2016, 04:08:21 pm
@Solarius
I didn't invent this five minutes ago just to start a flamewar or something.

This is my honest assessment, after playing quite a lot.

All maps with artificial lighting look total crap at the moment (sorry for the expression) and maps with natural lighting also look just bad to me. The jagged edges of the cone of light (when going diagonally along the tiles) are pretty irritating and sudden bursts of