aliens

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Yankes

Pages: 1 ... 4 5 [6] 7 8 ... 212
76
OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread
« on: January 24, 2024, 10:51:21 pm »
There is some programs that are designed to edit save files, would they be better for this task?

77
OXCE Support Y-scripts / Re: [Examples] More Y-Script examples
« on: January 20, 2024, 08:46:46 pm »
Some random example of new custom vapor:
Code: [Select]

  - update: STR_BLASTER_BOMB
    power: 10
    blastRadius: 2
    vaporColorSurface: 6
    vaporDensitySurface: 10
    vaporProbabilitySurface: 100
    scripts:
      vaporParticleAmmo: |
        var int temp;
       
        set subvoxel_velocity subvoxel_trajectory_forward;
        muldiv subvoxel_velocity -3 2;
       
        random.randomRangeSymmetric temp 100;
        subvoxel_velocity.addX temp;
        random.randomRangeSymmetric temp 100;
        subvoxel_velocity.addY temp;
        random.randomRangeSymmetric temp 100;
        subvoxel_velocity.addZ temp;
       
        begin;
          var int last 6000;
          sub last subvoxel_trajectory_distance_max;
          add last subvoxel_trajectory_distance;
         
          if gt last 0;
            set temp 100;
            muldiv temp last 6000;
            random.randomChance temp;
            if gt temp 0;
              muldiv subvoxel_velocity last 6000;
            end;
          else lt subvoxel_trajectory_distance 6000;
            muldiv subvoxel_velocity subvoxel_trajectory_distance 6000;
          end;
        end;
        subvoxel_velocity.addZ 200;
        return;
  - update: STR_LASER_RIFLE
    vaporColorSurface: 5
    vaporDensitySurface: 1
    vaporProbabilitySurface: 100
    scripts:
      vaporParticleAmmo: |
        # noting
        return;
  - update: STR_RIFLE_CLIP
    vaporColorSurface: 2
    vaporDensitySurface: 17
    vaporProbabilitySurface: 100
    scripts:
      vaporParticleAmmo: |
        var int off;
        var int temp;
       
        if lt particle_number 3;
          var Position up subvoxel_trajectory_up;
          var Position right subvoxel_trajectory_right;
          var int sin;
          var int cos;
         
          set sin subvoxel_trajectory_distance;
          set cos subvoxel_trajectory_distance;
         
          wavegen_sin sin 10000 8;
          wavegen_cos cos 10000 8;
         
          mul up sin;
          mul right cos;
         
          set subvoxel_offset up;
          add subvoxel_offset right;
          set subvoxel_velocity 0 0 0;
          set subvoxel_acceleration 0 0 0;
          set subvoxel_drift 10;
         
          set subvoxel_velocity subvoxel_trajectory_forward;
          mul subvoxel_velocity -1;
         
        else lt particle_number 5;
       
          add vapor_color -2;
          set subvoxel_drift 50;
          set subvoxel_velocity subvoxel_trajectory_forward;
        else lt particle_number 12;
          # set off subvoxel_trajectory_distance;
          # wavegen_sin off 1200 5;
          set vapor_color -1;
          # add vapor_color +1;
          # set subvoxel_velocity 0 0 150;
          # set subvoxel_acceleration 0 0 off;
        else;
          var int sin;
          var int last 6400;
          sub last subvoxel_trajectory_distance_max;
          add last subvoxel_trajectory_distance;
          if gt last 0;
            #hit point
            add vapor_color -2;
            set subvoxel_offset subvoxel_trajectory_forward;
            muldiv subvoxel_offset last 256;
           
            random.randomRangeSymmetric temp 500;
            subvoxel_velocity.setX temp;
            random.randomRangeSymmetric temp 500;
            subvoxel_velocity.setY temp;
            random.randomRangeSymmetric temp 500;
            subvoxel_velocity.setZ temp;
           
            set subvoxel_acceleration subvoxel_velocity;
            muldiv subvoxel_acceleration -1 50;
          else lt subvoxel_trajectory_distance 6000;
            add vapor_color +1;
            #start trajectory
           
           
            set subvoxel_velocity subvoxel_trajectory_forward;
            mul subvoxel_velocity -4;
           
            random.randomRangeSymmetric temp 100;
            subvoxel_velocity.addX temp;
            random.randomRangeSymmetric temp 100;
            subvoxel_velocity.addY temp;
            random.randomRangeSymmetric temp 100;
            subvoxel_velocity.addZ temp;
           
            set subvoxel_acceleration 0 0 -10;
          else;
            # set sin subvoxel_trajectory_distance;
           
            # wavegen_sin sin 1000 -12;
            # add vapor_color -1;
            # set subvoxel_acceleration 0 0 sin;
            # set subvoxel_drift 1000;
           
            # set vapor_color -1;
          end;
        end;
       
        return;
In next week I prepare more concrete examples of some popular weapons trails.

78
OXCE Support / Re: tuSnap: -100 not working in OXCE
« on: January 20, 2024, 08:43:13 pm »
Negative costs are ban in OXCE as it would cripple logic that try reason about future actions.
For regain TU most cases you need get hit by something then script or custom damage types can restore TU.

79
OpenXcom Extended / Re: OXCE (OpenXcom Extended) main thread
« on: January 20, 2024, 06:57:21 pm »
In OXCE 7.11.2 I added script hook that alow changing how vapor particles moves (speed + acceleration) that allow lot more variability
in types of weapon attacks.
As hack you can even fake additional "hit" effects moving some particles closer to end of trajectory and spreed them from that point.
(rifle do something like this in example video)

80
Brutal AI / Re: Brutal-OXCE 8.1.1
« on: January 18, 2024, 12:14:46 am »
It then gets into this part of C++ I have difficulty understanding. With the Lambdas. For reasons I don't understand I can hover over some of the parameters to see their values but not all of them.
I meet problems like this when compiler optimalize out variable I like to look on. some times `volatile` to keep compiler hands away from it.

81
Offtopic / Re: Retro games
« on: January 17, 2024, 02:48:27 am »
Thing that intrigue me is that on old system you had direct access to hardware. No operating system, drivers, libraries. You one on one with hardware.
Probably at some point I will buy for my self 8bit computers like Commander X16 (modern clone of Commodore 64) or other similar one.

82
Help / Re: Game freeze sometimes when using invisible units
« on: January 15, 2024, 11:06:03 am »
This is not same problem like happens in XPZ caverns? when unit want move but not see unit in front of it?

83
Brutal AI / Re: Brutal-OXCE 8.0.3
« on: January 05, 2024, 03:43:29 pm »
I tried last version from git and have this crash, now I do not get crash in battle destructor. when I try quit game after it to try again, game crash on `Globe` destructor.
This look like big memory corruption.

[ps]

After changing some mods (last time I had some test mod enabled) game crash on `ctrl-a` and code at `PathfindingNode::connect`.
Probably Alpha is right ablaut cause of this error.

84
Brutal AI / Re: Brutal-OXCE 8.0.3
« on: January 05, 2024, 03:46:43 am »
The _battleGame that is being deleted in SavedGame::setBattleGame looks like a valid object. It has members like _missionType = "STR_TERROR_MISSION", which is what the mission is. And the parameter when it's called from DebriefingState::init() is just a null-pointer. So it tries to delete the current valid _battleGame-object and then set the _battleGame-pointer to nullptr.

The issue really seems to be deleting the _nodes and _altNodes-vectors. (std::vector<PathfindingNode> _nodes, _altNodes;)

According to ChatGPT it could be problematic that the PathfindingNode-object has a pointer to another PandfindingNode via PathfindingNode* _prevNode;

"The PathfindingNode class seems to contain pointers (PathfindingNode* _prevNode) that reference other PathfindingNode instances, forming a linked structure. When you're using std::vector to manage a collection of PathfindingNode instances and they contain interconnections via pointers (_prevNode), deleting these nodes within a std::vector can potentially lead to issues.

If nodes are connected in a complex manner (such as forming a linked list or a graph), deleting them within a std::vector could break those connections and cause issues when pointers are no longer valid after deletion."
And how this could affect anything? do `PandfindingNode` try delete `_prevNode`? No, it could even work without any destructor.
ChatGPT blindly try guess some thing without no understating of part of this code.
I suggest small change, set `_missionType = "F*** UP";` in destructor and put break point before that, and see if any break point stop, object do not have this value already there. You slimly do not rule out possibility of double delete of this object. If object is garbage it still hold data, whole point is normally you can leave trash behind if nobody can notice, and in case of string it can still hold value as `std::string` is allowed to have buffer inside itself for charters. Alterative it still point to old memory that had text. And in case of `std::vector` it could be this second case.

85
Brutal AI / Re: Brutal-OXCE 8.0.3
« on: January 04, 2024, 11:31:22 pm »
@Xilmi
Problem could be call to `~SavedBattleGame` it self. If you double delete then you make hell break loose, as its our favorite UB and effect is unpredicted.
On some compilers work "fine" on other crash instalty. or random and after some time whole game get corrupted and break in unrelated place.
See code:
Code: [Select]
void SavedGame::setBattleGame(SavedBattleGame *battleGame)
{
delete _battleGame;
_battleGame = battleGame;
}

What if `_battleGame` and `battleGame` point same objects? or you call `setBattleGame(x); setBattleGame(x); setBattleGame(x)`?
You need check what exactly is pointed by `_battleGame`, is this valid object? or some garbage?

Overall this is one of OXC few faults, manual memory management. (mainly as it used C++98 standard), in OXCE we use C++17 that have lot of
tools that fix problem like this making ownership of pointer more explicit (like `std::unique_ptr`, use `std::optional` or dropping `*` and use `std::move`).

86
Help / Re: Physical training facility implementation
« on: January 04, 2024, 09:04:45 pm »
was this not warboy mod?

87
OXCE Support / Re: Hangar storage
« on: January 04, 2024, 04:40:39 pm »
This is compatibility hack for original UFO, as craft storage is always included to total storage in OXC, this mean OG have more free space than OXC.
To fix it we add some small storage for craft items and weapons to have similar balance as OG.

88
Brutal AI / Re: Brutal-OXCE 8.0.2
« on: January 04, 2024, 12:07:58 am »
Simply some code indirectly access it. There is lot of processing after mission end. And of of function doing something else call your function.
Like there is function that do A, B and C, where A and B is needed for mission end but C that is not needed require checking patfinding.

Beside you you not have debugger that stop when crash happens? you should have function backtrack of crash site and see from where
this code is called.

Some times fix is simply add `if` in strategic position, there is lot "fix" like this already in OXC and OXCE (I prefer less hacky solution but some times it impossible).

89
OXCE Bugs FIXED / Re: X-Com-Files doesn't run on 7.10.3
« on: January 02, 2024, 07:23:44 pm »
This is feature of OXCE, we can declare that some functionality will be deleted at some point, and madders have time to prepare.
Before given year, game only warn, on given year game will reject load of given mod (still can be overridden by user) and finally after given
year, functionality will stop to work even if user try override it.

And yes, it use version time as it easy to predict.
Another bonus is if you compile old version it will behave exactly same as before.


Why code like this is needed? Some times fist version of functionality was lacking and was replaced by lot better version.
Another thing is some old code prevent better version in future.
This allow us to remove some old bad code and give most of mods time to adapt to change.

90
The X-Com Files / Re: [Submod] Everyone surrender
« on: January 02, 2024, 03:36:57 pm »
Then if you do not want crash then use `update:` as it only spam logs when do not find rule with given name.

Pages: 1 ... 4 5 [6] 7 8 ... 212