OXCE (OpenXcom Extended) main thread

[Meridian]

Can AI use sprint if this option is on for the player?

Maybe.
It was added here: https://github.com/MeridianOXC/OpenXcom/commit/8c3da2096de818b3ff3646f08a15bebc86ae5388
I never tried it, so can't confirm.

[Yankes]

Thanks, I think I get the basic idea, but I cant figured out the proper syntax  for that. Could you pls provide a script example of this? Like for instance, how do I apply a bonus to night vision, that comes from soldier bonus tag?

To use it you need define new tag similar to other tags but it not used like other ones:

Code: [Select]

extended:
  tags:
    RuleItem:
      ITEM_NV_GOGGLES: int
    BattleUnitVisibility:
      VISIBILITY_NV_GOGGLES: int
  scripts:
    visibilityUnit:
      - offset: 3
        code: |
          var int itemA;
          var int itemB;
          var int targetShade;
          var ptr BattleItem item;
          var ptr RuleItem type;
         
          #get info about left hand item
          observer_unit.getLeftHandWeapon item;
          item.getRuleItem type;
          type.getTag itemA Tag.ITEM_NV_GOGGLES;
           
          #get info about left hand item
          observer_unit.getRightHandWeapon item;
          item.getRuleItem type;
          type.getTag itemB Tag.ITEM_NV_GOGGLES;
          if eq visibility_mode null; #default visibility
           
            #if left or rigth item have NV bonus
            if or eq itemA 1 eq itemB 1;
              target_unit.getTileShade targetShade;
              if gt targetShade 9;
                add current_visibility 48; #16*3 = 3 tiles better visibility in dark
                set visibility_mode Tag.VISIBILITY_NV_GOGGLES; #toggle to NV mode
              end;
            end;
          else eq visibility_mode Tag.VISIBILITY_NV_GOGGLES; #assume that other script already set "NV" mode, we only add small bonus in that case
            if or eq itemA 1 eq itemB 1;
              add current_visibility 16;
            end;
          end;
         
          return current_visibility visibility_mode;


[Finnik]

To use it you need define new tag similar to other tags but it not used like other ones:

Code: [Select]

extended:
  tags:
    RuleItem:
      ITEM_NV_GOGGLES: int
    BattleUnitVisibility:
      VISIBILITY_NV_GOGGLES: int
  scripts:
    visibilityUnit:
      - offset: 3
        code: |
          var int itemA;
          var int itemB;
          var int targetShade;
          var ptr BattleItem item;
          var ptr RuleItem type;
         
          #get info about left hand item
          observer_unit.getLeftHandWeapon item;
          item.getRuleItem type;
          type.getTag itemA Tag.ITEM_NV_GOGGLES;
           
          #get info about left hand item
          observer_unit.getRightHandWeapon item;
          item.getRuleItem type;
          type.getTag itemB Tag.ITEM_NV_GOGGLES;
          if eq visibility_mode null; #default visibility
           
            #if left or rigth item have NV bonus
            if or eq itemA 1 eq itemB 1;
              target_unit.getTileShade targetShade;
              if gt targetShade 9;
                add current_visibility 48; #16*3 = 3 tiles better visibility in dark
                set visibility_mode Tag.VISIBILITY_NV_GOGGLES; #toggle to NV mode
              end;
            end;
          else eq visibility_mode Tag.VISIBILITY_NV_GOGGLES; #assume that other script already set "NV" mode, we only add small bonus in that case
            if or eq itemA 1 eq itemB 1;
              add current_visibility 16;
            end;
          end;
         
          return current_visibility visibility_mode;


Thank you very much!

[Yankes]

Small request to community, I mess with unit pathfinding in version 7.5.5 and probably break some thing, if someone look for bugs in new version I would be thankful.
In meantime I will mess with this code more and look for adding multipliers for move cost.

[pedroterzero]

I have a question because I want to set up some CI/CD for some IDT mods (everyone would be free to use it though, of course);

- would it be possible to run JUST the OXCE validation and exit immediately (preferably with non-zero exit code if validation failed, but it could also be scraped from logs)
- if so, would this validation require the vanilla [UFO] assets to be present? It would make the pipeline a bit more involved in that case, but not impossible.

If this can be achieved, when committing to GitHub, using GitHub Actions, I can set up a pipeline that does some basic sanity checking automatically.

Thanks for any insights

[Yankes]

This will require original data, at least for surfaces validation, some surfaces are from base game, if we skip then then it would report false positives.
Other data is not logically required to validate most of data but there are hardcoded checks for it to be present.

Another question is what it should load, as curretlyis expect very specific places to load mods (plus zip files).

Overall it would be preferred to add special mode for this only, some kind of new command line parameter that allow only loading `Mod` and return 0 or 1 depend if it throw exception.

[pedroterzero]

That would be awesome. But even if the vanilla game files are required, it would still be useful, but I would have to expand the pipelines to allow providing those files somehow. Making it a bit more complex to set up.

The most important bit would be the checking then exiting (with 0/1 exit code). If it wasn't dependent on vanilla files it would just be a bonus.

Overall it would be preferred to add special mode for this only, some kind of new command line parameter that allow only loading `Mod` and return 0 or 1 depend if it throw exception.

If this gets implemented, I would be very interested in it.

[BTAxis]

I noticed that the notes panel that can be brought up from anywhere via Ctrl+N, can indeed be brought up from anywhere, including the notes panel. It's possible to press the hotkey multiple times, and have to close the menu multiple times as a result. It might be a good idea to disable the keyboard shortcut when it's already open.

[Finnik]

Do you guys have any plans to fix that issue?

[Yankes]

There is multiple corner cases to consider when fixing some thing like this, maybe in some future I will visit this again as there still some cases I would like to fix.

[ps]

I look a bit on this case, it can't be easy fix by switch drawing background and unit as this back part is already drawn on top of background.
Problem is that tiles on front overlap back part.

[Finnik]

Yeah, I guess... Is there an option to crop it?

[Yankes]

crop what exactly? And when exactly?
Yesterday I think ablaut it and how exactly could possible to tackle this problem. And I probably get solution that could fix it and other similar problems.
Right now in OXCE back part is drawn when game try draw back tile, but we could split this back graphic in half and draw each part with with parts that are on side tiles.

[Finnik]

crop what exactly? And when exactly?
Yesterday I think ablaut it and how exactly could possible to tackle this problem. And I probably get solution that could fix it and other similar problems.
Right now in OXCE back part is drawn when game try draw back tile, but we could split this back graphic in half and draw each part with with parts that are on side tiles.

[Yankes]

I make some initial test for solution (in attachment is example).

But I see it not fully fix it as wheat is so hight that is still easy peak out disc graphic.
Another thing is that now selection box do not go pass middle of disc as it use to.

[Finnik]

I wonder if the original game also had this bug?