Messages

1

OXCE Support Y-scripts / Re: Reshading BattleUnits

« on: September 17, 2023, 08:13:45 pm »

I got the two scripts to run. Also, it doesn't look like I can set a tag from recolorUnitSprite, to potentially transfer the original shade, since it is a readonly pointer. Given a test, it looks like it does each pixel at all offsets before moving to the next, but since I can't save that data, I can't just reference the original value. Also looks like global variables are readonly as well, and might not be possible to add to.

It is a .rul file, but it uses yaml rules? Probably a Notepad++ plugin to errorcheck exists.

Flickering. if it is averaged, shouldn't be able to change by more than 1, and not constant flicker back and forth when pitch-black. Also, it only occurs with TheXcomFiles active, rather than vanilla...
Reason is because of "personal Light" being exactly one below light threshhold, so each tile you move it goes from 9 to 10, so flickers between the two states. Just have to make sure to disable personal lights and it fixes it.

2

OXCE Support Y-scripts / Re: Reshading BattleUnits

« on: September 17, 2023, 03:44:27 am »

Well, it works well in vanilla, but when it runs with TheXcomFiles, it flickers between white and green shaded when a unit is moving. Obvious interference, and given how much shade shifts for shields, damage flash, daze, and probably other reasons I shouldn't be surprised, but I have no idea why it is flicking, and only when moving, when the units should have no other shade adjustment.

3

OXCE Support Y-scripts / Re: Reshading BattleUnits

« on: September 16, 2023, 09:10:41 pm »

What is burn?

Why not just expose the base sprite's color as something you can read?

Does the script run all offsets of a single pixel, or all offsets of a value for all pixels before repeating? In the former case, might be able to save data to a variable of some kind. However, any time I tried to have two scrips with different offsets, the second one wouldn't run, and wiki page has no examples of it.

And the really big question, why is indentation part of the script? If the indent isn't perfect the whole thing breaks, which is just so weird.

4

OXCE Suggestions OK / Re: Health Bar Over Soldiers' Heads

« on: September 15, 2023, 07:10:55 pm »

A better suggestion if probably an API request for the ability to draw sprite attachments to units, then you can make a mod that does this, or many other things.

5

OXCE Support Y-scripts / Re: Reshading BattleUnits

« on: September 15, 2023, 06:07:29 pm »

The glow is when the shade is enough to drop an already dark part.of the sprite to index 15 rather than past it,, and then trying to counter the shade by offsetting back by the same amount. Since it overflowed and was capped, that part of the sprite.got brighter than the original image, so the border and other dark parts all end up a lot lighter, to the point of a glow illusion. Makes it look washed out and wrong.

It is like trying to recover from a lossy compression. You can kinda do it, but there are always limits since the data is gone.
Only solution I can see is to somehow use the original sprite instead of the post-shade sprite

As for logging, yea, it runs way too often for not using a filter, but I have no idea how I would run the log on on, say, entering a new tile, once for each pixel.

Mod objective, if it wasn't clear, is to make it blatantly obvious whether a unit is illuminated or not, and if moving one step forward would change that. Initial intent was to fully override all shading to just have lit (0 shade) dark (8 shade) and black mask (15 shade/not drawn)
But with api limits, I seem to be limited to unit shading, so just showing if lit and if on border between light and dark seems best I can manage.

6

OXCE Support Y-scripts / Re: Reshading BattleUnits

« on: September 15, 2023, 05:07:27 am »

Alright, I think I mostly understand this, and have something that works better now. That said, Not sure how I would go about adjusting things before the initial function run, or override it. As is, I at least recover the small amount of remaining detail now, but obviously would prefer keeping all of it if possible.

I'm probably still doing this wrong anyway, and am unsure how to not have the green color get brighter the darker the tile is. I understand why it happens, shade caps at 15, so the darker the tile is, the more I increase the brightness. Which is suboptimal, but unsure how to fix that.

Also, if I try and brighten unit's it invariably seems to make them kinda glow, even if I just add a small amount, when the target is only slightly shaded. Always ends up washed out. I thought each point of shade offset all colors by 1, and reversing that, unless you fall off the 1-15 range, would undo the effect.

Also, is there a way to print to screen instead of log, or chose a specific pixel to log, and only once per "Change"? This is worse that Wc3 debugging. Or just debug message best practice?

Code: [Select]

extended:
  scripts:
    recolorUnitSprite:
      - offset: 1
        code: |
          var int tileShade;
          var int oldShade;
          var int newShade;
         
          unit.getTileShade tileShade;
          unit.getRecolor new_pixel;
          get_shade oldShade new_pixel;
         
          if le tileShade 9;
            # Fully Lit. Not on border.
            if ge tileShade 6;
           
              ## Reduce shade.
              #set newShade oldShade;
              #sub newShade tileShade;
              #add newShade 4;
              #limit newShade 1 15;
              #set_shade new_pixel newShade;
             
           
            end;
           
          else eq tileShade 10;
            # dark, on border. Leave as is.
           
            set newShade oldShade;
            sub newShade tileShade;
            add newShade 4;
            limit newShade 1 15;
            set_shade new_pixel newShade;
           
          else gt tileShade 10;
            # Dark, and not on border. Greenlight it, but keep it dark-ish
            set_color new_pixel 4;
           
            set newShade oldShade;
            sub newShade tileShade;
            add newShade 6;
            limit newShade 1 15;
            set_shade new_pixel newShade;
          end;
         
          return new_pixel;



7

OXCE Support Y-scripts / Re: Reshading BattleUnits

« on: September 12, 2023, 09:41:08 pm »

`old_pixel` is color of background, is used when you want have some pseudo transparency effects.

Understood. Useless here then. Explains the invisiblity though.

You need set both `set_shade` and `set_color` as both affect final color index of pixel (this is effective `index = (shade & 0x0F) | (index & 0xF0)` and `index = ((color << 4) & 0xF0) | (index & 0x0F)`).

I have both being used. What is the "Color index" and what is "Pixel"?
So set_shade sets the 1s place, while set_color sets the 16s place? Since its essentially a lookup table for the pallet imagine file. By default both are set to 0, because that is 0, and running both should set the full value.

What does setting the new_pixel actually do? It looks like, for the sprite being drawn, setting color sets the color for each drawn pixel. but setting both doesn't always set it all to a solid singular color, so it offsets the original selected color pixel in the pallet?

What value would I set to leave the entire thing unchanged?

Essentially I am confused on the mechanics.

You can too set value directly like `set new_pixel 232;`.

Yep, but same thing either way, and the set method sets both separate and I don't have to work out the result manually. Might simplify later admittedly.

Another thing is that global scripts are not perfect place to alter shade, as in most cases basic default script set shade past 16 that make pixel pitch black.
If you use `offset: -2` then your code will be run before basic script and have original pixel value but you should be careful as right after your script will be run default one and it will try to apply normal shade.

Offset says when it runs, and base code runs at offset 0, and all scripts run in ascending order.
Since that base code reshades/colors, I can't run it before 0, since that would just be overwritten by basecode. Not sure what you mean by be careful, because it wouldn't do anything, right?

Only (bad) solution for now is override all basic script in each unit but this will easy conflict with any other mod that try change this scripts.

As in full override whatever draw function is there?

8

OXCE Support Y-scripts / Reshading BattleUnits

« on: September 12, 2023, 07:24:45 pm »

So I am trying to write a script to adjust the shading of battleunits based on the background lighting, so as to highlight the difference between illuminated and not. However, using the Hit flash script and API
I have to say I am uncertain how to do it.

I can set color or set shade and white color, but I can't figure out what the original shade was, or what changing the shade does exactly. It also seems to strip the color (or set to white) when I set_shade but not set_color. Also, old_pixel doesn't appear to be the previous frame's "pixel" but rather full transparency status.

I probably have a significant misunderstanding of either how shades work, as well as what new_pixel does(I thought it was essentially a shift from the original sprite image moving right on a pallet for each pixel)

I've tried several different things, and this one works, but isn't ideal.

Code: [Select]

extended:
  scripts:
    recolorUnitSprite:
      - offset: 2
        code: |
          var int tileShade;
          var int newShade;
         
          unit.getTileShade tileShade;
         
         
       
          if gt tileShade 9;
            set_color new_pixel 4;
            set_shade new_pixel 12;
          else;
           
          end;
         
         
          return new_pixel;


9

Help / Battlescape ui additions.

« on: September 04, 2023, 07:18:40 pm »

In addition to changing the shade of an entity, is there a way to attach extra sprite(s) like xpiratez shows stun/fatal wounds (which seems to be built in, as it just adds sprites to set variables) add sprites to a selected location, or read/write motion scanner pings?

10

OXCE Suggestions Rejected / [Rejected] Sharp lighting divide

« on: August 26, 2023, 08:48:00 pm »

Rejection reason: same as here: https://openxcom.org/forum/index.php/topic,6869.0.html

What: make it so that tiles/pawns that are illuminated via light or daylight more clearly distinct from those not illuminated

Why: Given how important light is, especially in mods, the inability to easily see the difference between lit and unlit is frustrating. I would rather not have to guess or count tiles.

An alternate vision mod like night vision, a two-brightness level option, or a Sharp division at the lighting threshold would all be effective.

11

Work In Progress / [OXCE] Armor Chipping

« on: December 16, 2021, 08:17:41 pm »

This mod adjusts vanilla weapons to all deal pre-armor damage, and have reduced armor penetration. The general effect is to make all armor act more like ablative armor, and be worn down instead of punched through. This makes combat quite a bit less dynamite tag, and significantly reduces the number of one-shots on both sides, but also makes it impossible to entirely ignore any weapon. A pistol will eventually kill a Sectopod if it lets you get a hundred or so shots off before vaporizing you.

All normal weapons deal 20% pre-armor, and have 200% Armor coef. Stun weapons deal 5% pre-armor and have 120% armorcoef. Also, Chysalids have to deal health damage to infest.

It should feel more like NuCom, in that armor adds extra health, to an extent.

This all said, heavy plasma can still oneshot you in powered armor if you don't have a lot of health backing you up or it isn't to the front, and a blasterbomb is just as lethal.

12

Released Mods / [OXCE] HitFx, From XCF

« on: December 16, 2021, 08:07:37 pm »

This is a standalone copy of the Hitflash effect from The Xcom Files.

It causes units to flash when they are hit based on damage type dealt.

13

OXCE Builds & Ports / Re: OXCE v7.1.4 for Android

« on: December 06, 2021, 08:55:12 pm »

Well that solves my problem. Thanks.

14

OXCE Builds & Ports / Re: OXCE v7.1.4 for Android

« on: December 04, 2021, 02:09:12 am »

Inconvenient, but understandable. I was planning to use my phone as a separate ufopedia reference tool

15

Tools / Re: Weapon Balance Tool

« on: December 03, 2021, 08:33:14 pm »

Manual it is then. oh well.