Messages

1

OXCE Suggestions DONE / Re: [DONE][Suggestion] Making ufopaedia article hidden by default

« on: September 26, 2024, 09:43:22 am »

Done.

Sample ruleset:

Code: [Select]

startingBase:
  ufopediaRuleStatus:
    STR_CANNON_UC: 2
    STR_PISTOL: 2
    STR_PROXIMITY_GRENADE: 2
    STR_SMALL_RADAR_SYSTEM: 2


It will help a lot by hiding duplicate articles at start of damaged/ruined variants of buildings at start, but making them accessible via direct MMB click on facilities.

The issue with this, is when new technology gets added mid-game (during one of XPZ patches for example), it will have no effect, unless new game start.

I've implemented crutch like this to avoid this issue: https://github.com/WarStalkeR/OpenXcomExMore/commit/8e9a2d7c7c93766b4995feacdd1047e4f82e6770

2

OXCE Suggestions DONE / Re: [Suggestion] Making ufopaedia article hidden by default

« on: September 08, 2024, 10:05:36 pm »

I will gladly consider adding modding features if modders ask for it.

While making submod for XPZ, I was thinking it is a shame that all ruined versions of the facility can be seen only in debug mode, because they are hidden behind unresearchable technology (to avoid filling ufopaedia list and articles with unnecessary spam I assume).

PS: hiding pedia articles is a user feature, not a modder feature. Whatever the requirement is here, the solution would be different than proposed.

This idea is something like this:

Code: [Select]

ufopaedia:
  - id: STR_HANGAR_DAMAGED
    type_id: 6
    section: STR_BASE_FACILITIES
    requires:
      - STR_HANGARS_TECH
    text: STR_HANGAR_DAMAGED
    defaultUfopediaStatus: hidden
    listOrder: 19171And article is in the 'hidden' category by default. Player doesn't see it, once technology in 'requires' was researched, but can do MMB click on relevant facility in the basescape to open relevant ufopaedia article. Of course, if player wants - it can be seen in hidden category and can me changed to always visible.

3

OXCE Suggestions DONE / [DONE][Suggestion] Making ufopaedia article hidden by default

« on: September 08, 2024, 08:50:39 pm »

By default, all ufopaedia articles are assigned default visibility flag. The 'ufopediaRuleStatus' entry is only modifiable during gameplay via ufopaedia list (by right mouse button click on the entry).

Option to make specific article hidden by default will make possible to add proper ufopaedia entries for damaged/ruined facilities that will open, once you're clicking middle mouse button, but won't appear in the list nor will show up, when you switching to the next or previous ufopaedia entry.

So far I haven't found anything that allows me to make ufopaedia entry hidden on initialization or tech unlock.

Is there any chance to add something like this?

4

OXCE Suggestions Archive / Re: [Suggestion] Custom base sets and New Game starting base selection

« on: September 04, 2024, 03:08:06 pm »

Yes, I understand.

In one solution you can select it in the "Start New Game" GUI, in the other solution you can select it in the "Mods" GUI.
(in both solutions submods overwrite each other and the parent)
(the current solution requires multiple submods for multiple options, which I don't see as a disadvantage or a problem)

Exactly. Pretty much QoL (and a little bit flavor-text) feature.

Either way, I will be more than happy to receive your input regarding the code I wrote and how it can be improved (of course when you're free, since you have a lot of OXCE-related things to handle). I'm pretty sure there are some parts of code that could be done better and I have much to learn, when it comes to C++.

5

OXCE Suggestions Archive / Re: [Suggestion] Custom base sets and New Game starting base selection

« on: September 04, 2024, 02:16:06 pm »

we already have the ability to define custom starting bases, in mods and submods. I am not interested in having the "same" feature implemented multiple times.

As of right now it is possible to define only single custom starting base per submod. And next submod will overwrite it.

Here you can define base sets for various scenarios within same submod. Whether it is abandoned X-COM Base from First Alien War in Europe, pristine locked out Research Center in USA or forgotten and somewhat intact Nuclear ICBM Silo in North Korea, including them containing unique facilities for each base, and kick-starting completely different scenario chains.

6

OXCE Suggestions Archive / [Suggestion] Custom base sets and New Game starting base selection

« on: September 04, 2024, 12:27:14 pm »

Hello Meridian! I implemented code that allows to define custom base sets and (if related option is enabled) to select them in a new game menu. I was pretty much inspired by this XPZ submod: https://openxcom.org/forum/index.php?topic=12172.0 - then went to the chat, asked people about it and everybody pretty much welcomed this idea.

You can find relevant dedicated (atomic) commit here: https://github.com/WarStalkeR/OpenXcomExMore/commit/5fbd227d415efa55b399618acec030460b1c5172

This is how it looks right now:


Code-wise it requires modders to define in rule file something like this:
startingBaseSets:
- name: STR_INIT_BASE_NAME
  baseDefault:
    ...base code here...
And it follow exactly same code structure as in 'startingBase', so everything is well known.

Beside 'baseDefault' there is also 'baseBeginner', 'baseExperienced', 'baseVeteran', 'baseGenius' and 'baseSuperhuman' for each difficulty, just like with original 'startingBase' and 'startingBaseDIFF'. Localization-wise, for every base set name (i.e. STR_INIT_BASE_NAME), you also need to add '_DESC' variant with description (i.e. STR_INIT_BASE_NAME_DESC) and base set is good to go.

You might see me using 'YAML::Clone()' in code a lot - but that's because not I wanted, but because sometimes when variables were reset via empty 'YAML::Node()' actual mod data was lost.

As always, if anything else needs to be improved, please tell me so and I will work on it. Thankfully, a lot of similar code already exists, so I didn't had many changes to screw everything up in a very horrible, horrible manner.

And if everything is good to go, give me a green light and I will create dedicated OXCE commit and pull request.

7

XPiratez / Re: [Submod] Alternate Starting Bases

« on: September 03, 2024, 11:47:52 pm »

Well, your submod inspired me to create feature... And I created it:

Will be posting the commit itself into suggestions a little bit later.

8

XPiratez / Re: [Submod] Alternate Starting Bases

« on: August 28, 2024, 09:41:25 am »

Hmm... Sounds like nice idea for a new feature to add: preset base selector at start of the game.

9

OXCE Suggestions NEW / Re: [Suggestion] True Hybrid Capabillities for Crafts.

« on: August 19, 2024, 06:59:23 pm »

At some point me and Yankes were discussing it. But if we're to add proper altitude, we also need tools/data to identify height and depth on the globe. And if we're taking into account height and depth, we also need proper pathfinding for crafts and UFOs alike.

10

OXCE Suggestions OK / Re: [Suggestion] Bigger Craft Sprites (Configurable)

« on: August 19, 2024, 06:52:14 pm »

Another option is to provide override, which doesn't come from a spriteset (similar how `modSprite` in UFO ruleset was done).
Instead one could have a new attribute, for example `modSpriteBasescape: myCustomSpriteNameForBigHarvester_Base`.
And the size would come from the sprite itself, instead of having to specify it on the craft.

Then I will rework it accordingly. What I implemented is pretty much a crutch.

Btw. the craft has 3 related sprites: basescape, dogfight and minimized dogfight which currently all share the size; above commit doesn't take care of the other two yet.

Well, last two are tied to the interface, so unless interface is being completely reworked/replaced/moddable, 2nd and 3rd using default size will be OK. The only issue is the first one, if you want bigger (or more detailed) craft in the basescape, you're still limited to 32x40.

The best solution (IMHO) is to not do anything.
32x40 was enough for everyone so far, even for biggest of aircraft, I haven't heard any complaints from modders yet.
And the size limitations exist too (for example in the Dogfight UI)... having different size sprites in Dogfight and in Basescape feels weird.

This is only for now, until you implement custom craft types/categories (similar to custom weapon types/categories) but for hangars (or some other variant of craft slots). Once it will be possible to have dedicated hangar type for example for space battleships, I expect modders rush to add 2x3 and 3x3 hangars for them... And at this point 32x40 will be far from enough.

P.S. Conqueror from XPZ with its size pretty much begs for 3x3 (or at least 2x3) dedicated hangar (actual reason why I started multi-craft slots, craft classes and bigger basescape sprites).

11

OXCE Suggestions OK / Re: [SUGGESTION]Custom Hangar/Craft types

« on: August 18, 2024, 09:55:41 pm »

Another way we may eliminate this counter-example is if we allow only one class of hangars that allow multiple vehicle types per base.  All the rest of hangars might as well be strictly class-specific.

I'll tell you from the get go that any solution that requires to limit modding capacity of the game is horrible solution (from modding perspective). Because for example, if somebody wants to implement a hangar that can only house aircrafts and submarines and one more hangar type that can house tanks and aircrafts - it won't be possible to implement with your approach.

Your approach will limit modder to:
1) Normal hangar can only house aircraft, submarine or tank.
2) Unique/special hangar that can house aircraft, submarine and tank.

Alternative approach to what I implemented is simple brute-force: let modder assign, what crafts exactly can be housed in the specific hangar and push onto player the decision which craft will be put in which hangar and which other slots to block.

12

OXCE Suggestions OK / Re: [Suggestion] Bigger Craft Sprites (Configurable)

« on: August 18, 2024, 09:33:20 pm »

Craft sprites come from BASEBITS.PCK sprite set (internally saved as SurfaceSet).

SurfaceSets support only sprites with the same width and height for all sprites... otherwise the SurfaceSet's members _width and _height would be meaningless.

The thing is, I've made this change because after testing this approach:

Code: [Select]

extraSprites:
  - type: BASEBITS.PCK
    files:
      ## Vanilla XPZ Craft Sprites Override
      262: Resources/Planes/Harvester_Big_Basescape.png
I found out that no part of the sprite was cut, despite it being 44x50 instead of 32x40.

And since sprite wasn't cut, but only incorrectly centered as if it is 32x40 sprite, I used easiest approach to resolve it: is to add offsets to craft that will be using bigger sprites. And to avoid bothering modders with offset calculation, modder only requires to write actual size of the sprite and offsets will be calculated automatically.

This change doesn't look correct to me.

Well, I don't really see another way how to handle it without making code changes excessively complicated.

EDIT: I also checked other BASEBITS.PCK sprites: 32x40 is only for crafts, 32x32 is for facility basescape tiles.

13

OXCE Support / Re: [Suggestion] spriteFacility for 2x2 facilities.

« on: June 07, 2024, 09:53:28 am »

The "spriteEnabled" is your best friend https://www.ufopaedia.org/index.php/Ruleset_Reference_Nightly_(OpenXcom) to allow "spriteShape" and "spriteFacility" for facilities bigger then 1x1. Was implemented quite some time ago.

14

OXCE Suggestions OK / Re: [Suggestion] Craft size and Hangar capacity

« on: June 07, 2024, 09:46:25 am »

At least two people have already implemented hangar changes, one with sizes and one with types. The latter is available in BOXCE. Neither is nowhere near as simple as you two try to portray it, and Meridian has more potential problems to solve than either of the two, due to OXCE being the modding standard these days.

Yeah, I had to go along with sizes (which also can be granulated into classes/types, if you want), because otherwise there is no way to sort and allocate them algorithmically in a proper manner.

15

OXCE Suggestions OK / Re: Multi-Craft Hangars, Craft Sizes, Custom Craft Classifications & More...

« on: May 08, 2024, 10:27:30 am »

so we may have still to wait eons to see it? 

Because implementing a whole new parameter for crafts and sorting via it is very complicated. I've refactored my craft size and multi-craft hangar code like 5 times, before it became decent looking and with proper sorting.

Just simple code for modifiable soldier/vehicle craft stats that was merged into default branch had to be heavily refactored by Meridian. You even can see the comparison somewhere in the discussion.