Topics

16

From the Ashes / From the Ashes - initial release!

« on: April 17, 2022, 02:25:03 am »

Greetings everyone, I am incredibly excited to introduce my project, X-Com: From the Ashes, to the community!
It is a global conversion to OpenXcom. During the alien invasion, X-COM's initiative failed, alien agents infiltrated the ranks of most major governments, and within a few months, they were placed in a puppet regime. The true motives of the aliens remain obscure. Their hostile activities are skillfully hidden from the public. There is no support from the Council of Funding Nations, and Council members loyal to X-COM are scattered and remain concealed. The player will need to learn how to survive in the new circumstances, conduct an undercover struggle against alien forces, and cooperate with global organizations involved in the conflict.

This project is more than just a mod for OpenXcom, as it uses its own version of the game engine. There are many entirely new mechanics in the game - diplomacy, covert operations, new tactical mission objectives, loyalty, and much, much more. You can see the full list of engine features here: https://github.com/723Studio/OpenXcom_FTA/wiki

Download installer for Windows from Mod.io: https://openxcom.mod.io/from-the-ashes?preview=17bd8b77fdab4b426a1e766383a7e38b
The process is similar to the OpenXcom installation. However, if you have problems with the installation, visit this page for a detailed description of the manual installation process: https://openxcom.org/forum/index.php/topic,10498.0.html

The campaign begins with the player having to defend the X-Com base from an assault of the Men in Black. Then you will need to assess the situation and learn how to use the new opportunities. Many aspects of game mechanics and balance have been changed, giving a fresh experience. However, the gameplay and visual design remain in the spirit of the classic 1994 game.

The game is in development, the current version is the initial release, in a sense it is a "vertical slice" of the game experience. The campaign is limited in time with the first 8 months, after which it will end automatically. While most of the mechanics have already been implemented and a significant amount of content related to the early game has been added to the game, much more is yet to come. Nevertheless, the release is necessary in order to gather feedback and get more ideas and inspiration to keep working.

I would be very grateful for any feedback, bug reports and suggestions. You can share it here or by joining or Discord server: https://discord.gg/aecJUvV4pA
Especially valuable to me is gameplay video, so if you stream your playthrough, it would be great if you could send me the link to it. The Discord server has a special channel for streaming your games, don't be shy, drop by there.
You can follow the development progress on the Twitch channel: https://www.twitch.tv/finnik723studio

Current version is well-balanced for 2ed ("Experienced") difficulty level. You might face some troubles on higher difficulty levels because you will have to learn a lot of new mechanics and discover your own META first. "Superhuman" difficulty now works not how I want it to be, as I want to form an extra challenge here. This would require a lot of effort, and I want to finish general development first.
You might notice some loose ends in story arcs, because it is still WIP.
Also, more engine features coming. We have a new hacking system almost done, and there is a solid concept for negotiation system. Future releases will also include soldier secondary stats, additional battlescape tactical objectives and many more interesting ideas are yet to be developed.
As for content part - I'm planning to focus myself on increasing mission variety for 4-8 month, supporting coming engine features with content and balancing difficulties.
The next big milestone is midgame, where I will introduce another 2 factions and encounters with aliens. I'm planning to finish the most major engine work before this. Currently, engine C++ coding takes like 70% of my time, so I lack of strengths to make huge amount of content I would like to see in the game.

The project would have been unthinkable without the tremendous work that the OpenXcom and OpenXcom Extended developers accomplished before me. In addition, I have borrowed some free content from other authors. The detailed list of credits can be found here: https://github.com/723Studio/X-Com-From-the-Ashes/blob/master/LICENSE.md#credits

Most of the game's content is non-compilation code distributed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0). You are free to share and adapt the materials only for non-commercial purposes and when providing appropriate attribution.
However, some assets were developed by professional artists for a fee specifically for FtA, and I have full rights to it. So if you wish to use the assets in your project, please read the license terms: https://github.com/723Studio/X-Com-From-the-Ashes/blob/master/LICENSE.md#licensing

17

OXCE Suggestions DONE / [DONE][SUGGESTION] More precise define enemy count in alienDeployments.data

« on: December 30, 2021, 12:57:04 am »

We currently can specify `lowQty`for 0 difficulty and `highQty`for 5th, that assumes linear approximation of enemy count for other difficulties. I would like to suggest a new optional property 'medQty` that would specify Veteran difficulty enemy count, thus we could make nonlinear difficulty rise, with, for example, small grow on beginner-veteran and more rapid on experienced-superhuman. If not specified ('medQty` <= 0) we use vanilla logic.
To me, it looks like a tool to design a more precise balance for missions.

18

OXCE Suggestions Archive / [SUGGESTION] YS tags instead of researches as campaign progression

« on: December 29, 2021, 10:57:52 pm »

Probably, I can also rise another topic:
Currently, modders widely use researches as a progression triggers, very decent amount of researches in many mods are never shown to the player. It's being supported by devs with a very wide API, where you can add research as discovered at the background with arcs, events, deployments. They are used as triggers for arc/event/mission scripts to run campaign logic. We can get researches in YS, which is awesome, and we can disable research. We can interrupt ongoing missions and events with research being discovered. For many cases, it is enough, but I would like to know if that is the desired way for OXCE and you guys would like to keep expanding it.

For instance, I've looked into UFO:AL, they use LUA scripts to process campaign logic. In OXCE we have YS, that already has tags in SaveGame. There we can have any variable in form of integer or string value, not just boolean (is this research discovered?). I had cases where I was needed integer value for mission triggers, and I had to solve it with multiple copies of research and scripts. Also, we are limited to setting trigger variable (research) to false, as we can't set it back to true (disabled researches cant be discovered in any way) I can see it is not a small task and would require to add hooks for, many places where we check or discover/disable researches, but with this we would get a much more flexible system.

19

OXCE Suggestions DONE / [DONE][SUGGESTION] Research for mission success, fail and site despawn

« on: December 29, 2021, 10:45:27 pm »

Due to my project complex mission progression, it turns out I need to specify several researches to be unlocked for both mission success and failure cases. I'd like to know if that can be done in OXCE (if it is a required feature for other modders), or should I do that myself in my branch? I can also make it based on OXCE and commit pull request if desired. AFAIK, it's a pretty small code change.

[Spoiler]

20

Tools / World Editor request

« on: October 14, 2021, 03:53:20 pm »

I am pretty new to the world editing, but it seems to be the most painful part in the modding. AFAIK, there is only 2 options - Use Volutar editor (sorry, cant find the link to it), or use Falco's tool (https://openxcom.org/forum/index.php/topic,2835.0.html). There are not compatible, as Volutart's editor changes binary data file, and Falco is using ruleset as data format.

I want to make globe a bit more precise to real maps, so I was needed to use background image under data layer. I failed to load background to Volutar's editor, so I chose Falco's tool. It is fun to use, but it is far from perfect. First, it looks like it uses old data format, current OXCE `region` and `globe` data is recommended to store. Again, I am not an expert, but I came to this:
https://github.com/723Studio/X-Com-From-the-Ashes/blob/197d086090f4fcacab4df316d4065b95bc102e2e/Ruleset/globe_FTA.rul
https://github.com/723Studio/X-Com-From-the-Ashes/blob/197d086090f4fcacab4df316d4065b95bc102e2e/Ruleset/regions_FTA.rul

As it has big difference to Falco's export/import format, working brings a lot of pain.

Another problem is that Falco's tool is using cylindrical projection, so the closer you are to the pole, the bigger errors you can make. This makes it's snapping fails, and brings gaps on the game's globe, that are not editable in web:

Spoiler:

Another issue - it is not very precise when it comes to mission zones rectangles, it is very hard to work with small zones.

How do you think, is it worth making the globe editor as part of game engine, like marvelous Ohartenstein's Map Editor (https://openxcom.org/forum/index.php/topic,8711.0.html)?

21

OXCE Suggestions Archive / [SUGGESTION] Patrolling over mission site

« on: October 13, 2021, 12:43:15 pm »

I thought there could be a place to improve QoL. Currently, when you arrive at the mission site, you can choose to patrol over it, in order to wait for the daylight. But when the time comes, the player goes to the craft actions state, then hit "Select new target" and then selects the site that is under the craft. How do you think, does it worth another making another button to avoid selecting destination?

For instance, when we choose to patrol over a mission site, we can make a link between the craft and the mission site. We break this link on 1) new target, but current site was selected, 2) low fuel.
Thus, when we select the craft actions, we could create a new button, that would tell the craft to deploy mission. That would save us a few pointless mouse clicks.

This link would allow us to make another feature - alert the player, that mission site is about to despawn and he or she has to choose return to base or deploy now, as we can't wait any longer. Ofc, both should be hidden under ruleset toggle or option.

22

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:

23

OXCE Suggestions DONE / [DONE][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`

24

OXCE Suggestions OK / [Suggestion] 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.

25

OXCE Suggestions DONE / [DONE][Suggestion] isUsed property for base facility

« on: March 21, 2020, 06:27:11 pm »

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!

26

OXCE Suggestions DONE / [DONE][Suggestion] cantBeBuiltWith property for xcom base facilities

« on: March 20, 2020, 11:23:50 pm »

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!

27

OXCE Suggestions OK / [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.

28

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!

The X-Com Files Pedia

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

Upd: link was updated, as we moved.

Upd: link updated again to Trigram Reactor.

29

OXCE Suggestions DONE / [DONE][Suggestion] Possibility to choose groups in addLine mapScript command

« on: January 06, 2020, 07:55:35 pm »

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.

30

OXCE Suggestions DONE / [DONE][Suggestion] Custom UFO for dummy/blank 'addUFO' mapscript command

« on: November 29, 2019, 01:11:26 pm »

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.