Author Topic: [OLD] Old OXCE discussion thread  (Read 663752 times)

Offline ivandogovich

  • Commander
  • *****
  • Posts: 2381
  • X-Com Afficionado
    • View Profile
    • Ivan Dogovich Youtube
Re: [EXE] OpenXcom Extended
« Reply #855 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;'
« Last Edit: July 19, 2016, 01:50:51 am by ivandogovich »

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 3194
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #856 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.

Offline ivandogovich

  • Commander
  • *****
  • Posts: 2381
  • X-Com Afficionado
    • View Profile
    • Ivan Dogovich Youtube
Re: [EXE] OpenXcom Extended
« Reply #857 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?

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 3194
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #858 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.
« Last Edit: July 20, 2016, 02:29:29 am by Yankes »

Offline ivandogovich

  • Commander
  • *****
  • Posts: 2381
  • X-Com Afficionado
    • View Profile
    • Ivan Dogovich Youtube
Re: [EXE] OpenXcom Extended
« Reply #859 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!)
« Last Edit: July 20, 2016, 05:26:58 pm by ivandogovich »

Offline Dioxine

  • Commander
  • *****
  • Posts: 5412
  • punk not dead
    • View Profile
    • Nocturnal Productions
Re: [EXE] OpenXcom Extended
« Reply #860 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.

Online Meridian

  • Global Moderator
  • Commander
  • ***
  • Posts: 8598
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #861 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).

Offline ivandogovich

  • Commander
  • *****
  • Posts: 2381
  • X-Com Afficionado
    • View Profile
    • Ivan Dogovich Youtube
Re: [EXE] OpenXcom Extended
« Reply #862 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;                                                             
« Last Edit: July 20, 2016, 06:23:36 pm by ivandogovich »

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 3194
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #863 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

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 3194
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #864 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.

Offline ivandogovich

  • Commander
  • *****
  • Posts: 2381
  • X-Com Afficionado
    • View Profile
    • Ivan Dogovich Youtube
Re: [EXE] OpenXcom Extended
« Reply #865 on: July 21, 2016, 02:00:38 am »
Thanks a ton! Its working! :D  Now just to clean up all my rulesets. :)

Offline Dioxine

  • Commander
  • *****
  • Posts: 5412
  • punk not dead
    • View Profile
    • Nocturnal Productions
Re: [EXE] OpenXcom Extended
« Reply #866 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.

Offline Yankes

  • Moderator
  • Commander
  • ***
  • Posts: 3194
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #867 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?

Offline Starving Poet

  • Colonel
  • ****
  • Posts: 265
    • View Profile
Re: [EXE] OpenXcom Extended
« Reply #868 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.

Offline Dioxine

  • Commander
  • *****
  • Posts: 5412
  • punk not dead
    • View Profile
    • Nocturnal Productions
Re: [EXE] OpenXcom Extended
« Reply #869 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...