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.


Topics - Finnik

Pages: [1] 2
1
IDT Modding Hub / Community Extended LOFTEMPS
« on: January 12, 2021, 09:36:23 pm »
Hello all!

This topic could be interesting to modders, especially for those who like to create new interesting maps.

As you might know, the OXC, just as the original game has actually a 3D battlescape engine behind flat sprites. To process the shape of all map tiles, the game uses LOFTEMPS - "Line of Fire Templates" table, which creates a 3D voxel representation of the tile https://www.ufopaedia.org/index.php/LOFTEMPS.DAT.



That data is stored in a binary file UFO\GEODATA\LOFTEMPS.DAT and can be edited with any HEX editor. You might also notice, that the vanilla LOFT layers set has a lot of pretty specific to vanilla tiles, but some times this set can limit your creativity of tile creation. The thing is that as far as I know, for all those years we are modding OXC(E), nobody made any editions to that file. Thus, we can share maps we are creating, and do not worry if their LOFT dataset would be compatible - we all use the same file. Sadly, the engine was not meant to process this file modularly, so all terrains in all loaded mods should use the same file, other cases are not supported.
This could be a problem for terrain-sharing projects, like Community Mod Pack (https://openxcom.mod.io/community-map-pack).

With this project, I want to achieve two goals:
  • Push LOFT we are using to its limits (AFAIK it's 255 layers, and UFO/TFTD uses only 112/114 layers) with extra shapes we would like to have in terrains we are creating.
  • Keep terrains in the OXC community compatible with each other.

For that, I am creating a new LOFTEMPS.DAT file with HEX editing, and I want to fill it with shapes, that are required by modders. I would like then if we all agree on it to include it to CMP and major mods. The idea is already supported by some modders, and to organize proposing of bitmap shapes I am planning to use google doc:



If you would like to contribute to the process, let me know with a PM here on the forum or via Discord - Finnik#0294 (preferably via discord, so I will answer faster  ;) ), I will send you an access link to the file. For now, I am slowly adding proposed shapes to LOFTEMPS.DAT:



2
OpenXcom Extended / [SUGGESTION] item category check for y-scripts
« on: July 26, 2020, 01:51:29 am »
I would like to share my first tiny step into coding y-scripts. Many thanks to Yankes for inspiration and guidance!

https://github.com/MeridianOXC/OpenXcom/pull/72

The point here was to add a little QoL for a scripter that is working with many items. If you want to add some specific behavior to all items it one category, with that you do not have to add repeating tags to any item in the category, but add a single category check in the script itself. Let's say, we want to mod all our sniper rifles have some special behavior. Instead of adding tags to all of them defining it as a sniper rifle, you can use already most likely defined category item property.

So, an example of a script:
Code: [Select]
extended:
  scripts:
    damageUnit:
      - offset: 1 #test category script
        code: |
          var ptr RuleItem itemRuleset;
          var int check;

          damaging_item.getRuleItem itemRuleset;
          itemRuleset.hasCategory check "STR_SNIPER_RIFLES"; #returns 1 if defined category found in item's arrey; else returns 0 if the item does not belong to this category
          if eq check 1;
            debug_log 2 723;
            # do our stuff
          end;

          return;

UPD: method renamed to `hasCategory`

3
OpenXcom Extended / Jumping movement type
« on: July 04, 2020, 01:54:18 pm »
I noticed that among the modders from time to time the theme about the balance of flying armor and suggestions for new types of movement pops up. In my opinion, the possibility of free-floating for the player has too much influence on the balance of some mods, which places a strong focus on melee combat (for example, missions with monsters in XCF).
I would like to discuss the possibility of adding a third type of movement to the game along with walking and flying - jumping. For most gameplay moments, this type will be considered as walking (for example, when we select the node for unit spawning, jumping unit should spawn on walking nodes).
Essentially, this type can be something in between the two existing movement types, I would imagine playing for a unit with the jumping armor this way. When we select a point to move, we cannot select a tile that has no floor (just like the walking type). So we can't finish the movement by jumping in a floating state. However, the route can pass through a tile without a floor, as it does if the unit can fly. At the same time, the unit cannot stop in the middle of the movement, being in a floating state. For example, a unit will not stop if it spotted a new threat (as it does sprint). If the unit is forced to stop (for example, a player presses the stop button - RMB, or we encounter other circumstances when the unit can't continue with the planned movement - it falls down because it can't stay floating (like walking type does it). And you can't make a jump if the unit doesn't have enough TU to finish the jump and finish it on a tile that has a floor. Maybe we would ask the player to hold some buttons like Ctrl or Alt to make sure he or she wants to define jumping trajectory, to handle most cases where the game would perform pathfinding not right.
It would also be good to take the cost of traveling in the jump to the armor properties so that you can set the cost of resources for each tile passed in the jump - for example, that it would require more TU, and would not consume energy; or that the jump also uses mana, and so on.
I understand that this is a pretty ambitious project, and I haven't covered all of the problematic cases that can arise, and it's also a noticeable complication of the current solution. But in my opinion, it would significantly expand the gameplay and could be in demand in many mods, so I would like to discuss it. Maybe somebody has already considered this idea or even considered its implementation in code, I would be very interested to know about it.

4
Regardless of how the problem with facility uniqueness constraint can be solved (https://openxcom.org/forum/index.php/topic,8017.0.html), we in The X-Com Files need another property for our facilities.
See, we want straightway to upgrade one building (say, HQ, or Bio Lab) to its advanced version without permitting the player to be able to build any other copies of that building - in other words, the player should have either normal HQ, or advanced one at a time, without any other options. We also have more such buildings. Currently, if player desire, even with a uniqueness constraint, that I mentioned above, the player can build normal HQ, and then advanced next to it, thus, having both of them at a time.

To solve this problem I would like to suggest this small addition to the code. Proposed syntax:

Code: [Select]
  - type: STR_CYBER_HQ
    maxAllowedPerBase: 1
    isUpgrade: true #default false
    buildOverFacilities:
      - STR_HQ

Here is a solution I can imagine at the moment:

https://github.com/MeridianOXC/OpenXcom/compare/oxce-plus...FinnikXCF:virtualCraft


Additionally, I think, we can check onLoad if `isUpgrade: true` was set, but there are no `buildOverFacilities:` defined. If so, stop loading with error for modder:

Code: [Select]
[21-03-2020_19-25-52] [INFO] Loading rulesets...
[21-03-2020_19-25-58] [ERROR] Error processing 'STR_LARGE_RADAR_SYSTEM' in facilities: Facility has property isUpgrade set TRUE, but buildOverFacilities property was not defined!

I would really appreciate feedback and comments!

5
Edit by Meridian: final solution here: https://openxcom.org/forum/index.php/topic,8017.msg125175.html#msg125175

Hello guys, im really interested what are you think about my tiny new feature for Open Xcom Extended in form of cantBeBuiltWith property for xcom base facilities.

Here is a sample ruleset code:
Code: [Select]
facilities:
  - type: STR_LARGE_RADAR_SYSTEM
    spriteShape: 1
    spriteFacility: 22
    buildCost: 800000
    buildTime: 25
    monthlyCost: 15000
    radarRange: 2577
    radarChance: 20
    mapName: XBASE_05
    cantBeBuiltWith:
      - STR_SMALL_RADAR_SYSTEM

What it actually does – its allows a modder to restrict certain facility to be built if the specified facility was already been built on that base. This will be especially useful for creating upgrades for unique facilities, that already using both buildOverFacilities and maxAllowedPerBase properties.
For example, in The Xcom Files we have the xcom HQ facility and its improved version. Thus, we would like to forbid the player to build a normal version of the headquarters if there is already an improved version, but we should allow building an improvement over the normal version of the headquarters.
There are not many changes:

https://github.com/MeridianOXC/OpenXcom/compare/oxce-plus...FinnikXCF:oxce-plus

I can make a pull request if it's ok. If not, please, let me know, I will correct it.

Any feedback from modders is also very welcome!




6
OpenXcom Extended / [Suggestion] Addition to rects in mapScripts
« on: January 11, 2020, 07:57:02 pm »
I've spent some time researching the problem, and I would like to discuss it. Let's look at vanilla urban terrain mapScript:

Code: [Select]
  - type: URBAN
    commands:
    - type: addCraft
    - type: addLine
      label: 1
      direction: vertical
      executionChances: 50
      rects:
        - [1, 1, 4, 1]
    - type: addLine
      label: 2
      conditionals: -1
      executionChances: 50
      direction: horizontal
      rects:
        - [1, 1, 1, 4]
    - type: addLine
      conditionals: [-1, -2]
      direction: both
      rects:
        - [1, 1, 4, 4]
    - type: addBlock
      size: 2
      executions: 4
    - type: fillArea
      blocks: [3, 4, 10, 11, 12, 13, 14]
      freqs: [3, 3, 2, 2, 2, 2, 2]
Here rects numbers like [1, 1, 4, 4] suppose you have constant map size, but it is defined in alienDeployment. If we will want to use this script in multiple deployments we will need to make copies of this script for each map size, which makes mod far less manageable, especially if we have complicated scripts. For example, we want to use the complex script for urban maps with map sizes from 40 (where you need to capture single or 2 enemy units) to 80, where there are huge war actions. It would be cool if we can define a number for rect from map size, for example, mapsize - 1. I've thought about it for some time and here what I'm suggesting.
As game expect rect numbers to be integers, we can use negative values for that. As we need to keep 0, you know, as 0, I suggest to treat value '-1' equal to map size, '-2' as map size - 1 and so on (if i < 0; i=mapsize - i + 1).
Thus, suggesting syntax would be like
Code: [Select]
    - type: addCraft
      rects:
        - [1, 1, -2, -2]
That makes sure we will not place xcom craft near the map border no matter what map sizes are. That can make sense if its map is. for example, a cave exists to all sides, and you don't want it to lead nowhere. Speaking of cave maps, there could be a funny script that will make a cave with no exits outside of the map:

Code: [Select]
  - type: TEST_CAVE_SCRIPT
    commands:
    - type: addCraft #handle xcom spawn
      rects:
        - [1, 1, -2, -2]
    - type: addLine
      direction: both
      verticalGroup: 4 #west border group
      horizontalGroup: 5 #north border group
      crossingGroup: 6 #NW corner group
      rects:
        - [0, 0, 1, 1] #places it to upper NW map corner
    - type: addLine
      direction: both
      verticalGroup: 7 #east border group
      horizontalGroup: 8 #soth border group
      crossingGroup: 9 #SE corner group
      rects:
        - [-2, -2, -1, -1] #places it to upper SE map corner
    - type: removeBlock #handle NE corner
      rects:
        - [-2, 0, -1, 0]
    - type: addBlock
      rects:
        - [-2, 0, -1, 0]
      groups: 10
    - type: removeBlock #handle SW corner
      rects:
        - [0, -2, 0, -1]
    - type: addBlock
      rects:
        - [0, -2, 0, -1]
      groups: 11
    - type: fillArea
      rects:
        - [1, 1, -2, -2]
      groups: [3]

I was looking to code and I'm confused with mapScripts, I'm not sure how ti do that elegant way. Rects processing is called multiple times by commands with a little difference. Probably I should make some method to process negative values before general processing, but i don't know how to insert it to selectPosition method same way and constructions like this look ugly to me:
Code: [Select]
bool BattlescapeGenerator::removeBlocks(MapScript *command)
{
std::vector<std::pair<int, int> > deleted;
bool success = false;

for (std::vector<SDL_Rect*>::const_iterator k = command->getRects()->begin(); k != command->getRects()->end(); ++k)
{
if ((*k)->x < 0) {
(*k)->x = (*k)->x - _mapsize_x + 1;
}
if ((*k)->y < 0) {
(*k)->y = (*k)->y - _mapsize_y + 1;
}
if ((*k)->w < 0) {
(*k)->w = (*k)->w - _mapsize_x + 1;
}
if ((*k)->h < 0) {
(*k)->h = (*k)->h - _mapsize_y + 1;
}
for (int x = (*k)->x; x != (*k)->x + (*k)->w && x != _mapsize_x / 10; ++x)
{
for (int y = (*k)->y; y != (*k)->y + (*k)->h && y != _mapsize_y / 10; ++y)

I wonder if i can place some processing in getRects method itself, but for it I need to transfer mapsize we have to it as arguments. Also, I think I should not place such calculations to a Mod part. I would be glad for any feedback and if the idea itself is worthful - some coding advice to implement it in a good way.

7
The X-Com Files / The X-Com Files online Wiki
« on: January 08, 2020, 01:56:21 pm »
We have Wiki about The X-Com Files mod, that contains pages for all game elements presented in the mod - research, production, items, armor, units, UFOs and X-Com crafts, facilities and much more!

https://thexcomfileswiki.github.io/

Wiki is also translated into Russian and Polish languages.
Any feedback is very welcome!

Upd: link was updated, as we moved.

8
We are making rather complicated terrain with roads moved to different terrain, so we add them with mapscript like that:
Code: [Select]
    - type: addLine
      label: 100
      terrain: URBAN_ROADS
      direction: vertical
We have a lot of interesting ideas for the roads - highways, railroads, etc, but we can't mix different type of roads into one terrain. So we need one terrain for ground roads, one for highway, and if we want to make crossroads with different type of roads - railroad under the highway, we need separate terrain for any possible combination, in order to make sure that addLine command will choose blocks of only one needed type per line. So, it would be very practical for mod developing to have an option to choose groups for addLine.

9
I'm planning to make some additions to XCF terrains (ofc, its free to everyone else to use it), and as it has a lot of deployments, that uses its very own UFO (that looks like cults houses, for example).
For that the use specific mapScripts with defined UFO in addUfo command. First, it leads to tons of copypasting in mapScripts. Second, it does not let them use default mapScript from the terrain, and that's an issue to my concept. Also, it's impractical to match deployment name with its UFO, as we have many-to-many relations here.

So I'd really love to have the option to define ufo directly in the deployment rule, I'm proposing such syntax:

Code: [Select]
alienDeployments:
  - type: STR_MY_FAVORITE_CULT_HOUSE
    width: 40
    length: 40
    height: 4
    customUfo: STR_CULT_HOUSE                 # <------
    terrains:
      - TERRAIN_WITH_OWN_SCRIPT1
      - TERRAIN_WITH_OWN_SCRIPT1
    data:
...

I'm not sure if I did it all right, I guess there could be a more elegant solution, but I hope that could help a little:
https://github.com/FinnikXCF/OpenXcom/commit/12ec74f3a77f2e458b3ffb8c801dca208b73dd0f
It looks to me like its possible to merge it https://github.com/MeridianOXC/OpenXcom/compare/oxce-plus...FinnikXCF:oxce-plus

With it, map generator will look, if there is addUfo command, but we have no UFO defined in the usual way, so it gets ufo rules for optional alienDeployment property.

I would really appreciate any feedback on that, and I really want to know if such a ruleset option would become available in the upcoming release of OXCE, as I really need it in my work with terrains for compensation for recent events.
@Devs, if there is anything I can do to make it more fitting to OXCE, please, let me know, I'm really motivated in that feature.

Update by Meridian: ruleset attribute name changed to 'customUfo'. Code modified and merged.

10
OpenXcom Extended / [QUESTION] Facilities only as upgrades
« on: August 11, 2019, 04:17:06 pm »
Can we specify somehow facility that will be able to construct only above specified facility, like an upgrade, but cant built standalone? Problem is if we need to upgrade the facility with maxAllowedPerBase: 1, thus upgraded version can be constructed next to it, not only above.

11
I LOVE Ctrl + Mid Click opening Ufopedia article from the purchase-sell state, and I think it would be very handy to have it for manufacturing screen when playing complicated mod like XCF. I imagine it's not hard to do if devs agree with that but do not have free time for it, probably I could practice myself a bit making that?  ::)

12
I`d like to discuss the idea of an adjusting game engine to handle the alien mission, that was already spawned with mission script, should be interrupted with research trigger, that was already spawned with mission script. We can disable mission generation with researchTriggers in mission scripts, but as they are processed monthly, it can't determine, if a mission should appear to player midmonth if he or she achieves trigger. So, for example, in XCF when a player terminates alien cult he can still get spawned missions sites with it, and it looks like a bug to a player.
I've made a video demonstration of my idea and commit code changes to my github repo https://github.com/FinnikXCF/OpenXcom/commit/fa887ae1b768cabbf18cf2d79b40a73dd03ed430

Please, let me know what are you thinking about it

13
I think it could be very useful for modders to have an additional option in mission script to check if the player has specified item. The script will check if the player has listed items and if conditions are met, it will run mission. Probably, syntax could look like that:

Code: [Select]
missionScripts:
  - type: treasureHunting
    missionWeights:
      0:
        STR_TREASURE_HUNTING: 100
    executionOdds: 100
    itemDependency:
      - item: STR_TREASURE_MAP
        needed: true #default is true
      - item: STR_TREASURE_CHEST
        needed: false #that means if already has an item, mission will not spawn

14
OpenXcom Extended / Alien base building as part of infiltration
« on: March 30, 2019, 10:37:06 pm »
It would be so cool if the alien base that is being built during the infiltration of aliens appeared within the limits of the country where the infiltration occurs. Otherwise, it seems very unnatural.

15
With help of gurus of C++ (thanks again Meridian, SupSuper, Yankes and Otto for explanations and support) ive add new property into starting conditions block, called needItem. this works very similar to allowedCraft, but it checks, if sending craft contains listed items, and if not, its not allowed to launch (and also land). Here is video demo:

If that feature is wanted for modders, may be it would be possible to add it to OXCE? I can commit it to github. Also im very noob for OOP and C++, so any comments and tips are wellcome.

Pages: [1] 2