Messages

1

OXCE Suggestions DONE / Re: [DONE][Suggestion] Background Image alternatives for Ufopaedia armor Pages

« on: October 10, 2024, 12:09:47 am »

Done.

Code: [Select]

interfaces:
  - type: articleArmor
    backgroundImage: BACK08.SCR


I haven't been able to test this feature yet, i guess is pending to be added into a future update, right?

sorry for the dumb question.

[Spoiler]

2

OXCE Suggestions DONE / [DONE][Suggestion] Background Image alternatives for Ufopaedia armor Pages

« on: September 25, 2024, 07:44:16 pm »

Hi, sorry for reviving this thread, even if this was solved, i have some imputs related to this general idea. My current work on Xeno Operations can require some of what what Alex_D was asking for (it might be exactly what I need).

For context, in the XENOPS mod, every Ufopaedia image has an intricate background. Therefore, something needed to be done to avoid the plain black background you get when you assign a Ufopaedia page to the armor.

Currently, this is achieved by adding a "dummy" version of the armor with the suffix "DISPLAY," which uses a special custom spriteinv. This sprite is manually created.

This is the REAL ARMOR

Code: [Select]

  - type: STR_FLIGHT_JUMPSUIT
    ufopediaType: STR_PILOT_UFOPEDIA_DISPLAY
    spriteSheet: XOPS_XCOM_0.PCK
    layersDefaultPrefix: HUMAN
    layersSpecificPrefix:
      8: FLIGHT_JUMPSUIT
    layersDefinition:
      M999: [this repeated a bunch of times, dont need to add it in this post]
    spriteFaceGroup: 6
    spriteFaceColor: &SpriteFaceColorAgent [same as above for this post]
    spriteHairGroup: 9
    spriteHairColor: &SpriteHairColorAgent [same as above]
    customArmorPreviewIndex: 0
    storeItem: STR_NONE
    loftempsSet: [ 3 ]
    corpseBattle:
      - STR_CORPSE_FLIGHT_JUMPSUIT
    frontArmor: 6
    sideArmor: 2
    rearArmor: 2
    underArmor: 2
    stats: &StatsForJumpsuit [avoided, same as above]
    damageModifier: &damageModifierJumpsuit [same as above]
    builtInWeapons:
      - STR_NULL_POCKET_LS
      - STR_NULL_POCKET_RS
      - STR_NULL_BACKPACK
      - STR_NULL_BELT
    units: &CompatibilityWithPilotUnits
      - STR_PILOT
This is the DUMMY

Code: [Select]

  - type: STR_PILOT_UFOPEDIA_DISPLAY
    spriteSheet: XCOM_0.PCK
    spriteInv: PILOTUFOPEDIA
    weight: 2
    loftempsSet: [ 3 ]
    frontArmor: 6
    sideArmor: 2
    rearArmor: 2
    underArmor: 2
    corpseBattle:
      - STR_CORPSE_FLIGHT_JUMPSUIT
    stats: *StatsForJumpsuit
    damageModifier: *damageModifierJumpsuit
- If I use the dummy, it shows as expected in the rest of the Ufopaedia [1].
- If I directly add the armor in the ufopedia.rul, it has a black background [2].
- I tried modifying the interfaces.rul to put a custom background by adding the tag "backgroundimage:" hoping to have the Ufopaedia article include that background and then display the unit paperdoll as it usually does, but this was not successful.

Code: [Select]

  - type: articleArmor
    backgroundImage: BACK08.SCR #same as weapons?, for testing
    elements:
      - id: button
        color: 239    # Blueish gray
      - id: text
        color: 8   # chalky
        color2: 71  # green
      - id: list
        color: 6   # grey
        color2: 71  # greenI wish it would work[3] like in the same manner like facility or weapons screens [4], as I already have the "empty" background image ready[5].
(regardless I still use typeufopaedia to signal which article the MMB should open when clicked for all color variants of the same armor).

My issues with the current problem:

Spoiler:

Even though I'm taking advantage of the nodes "&" and "*" to simplify the process of updating stats, I'm now working on adding extra versions of the armors intended for pilots. This requires me to add another EXTRA dummy armor for each one I create, and also a custom image for the specific armor. Due to the compound nature of this images, every little change or tweak I make to the paperdoll requires the whole spriteinv image to be redone entirely.

Expected benefits:

Spoiler:

Simplifying the process of creating new Ufopaedia armor articles with custom-made backgrounds would save me from all the extra work on images and reduce the amount of clutter and unnecessary bloat. In this specific example, around 15 dummy armor definitions and the images related to them would be eliminated. As I mentioned before, every time I change even a single bit, the spriteinv file must be redone to match both versions.

TL;DR:

Spoiler:

1).To have custom background images for the Ufopaedia armor articles, a duplicate dummy armor with a custom spriteinv is currently required.
2).Trying to change the background image associated with "type_id: 5 (armor)" inside the interfaces.rul "articleArmor" doesn't seem to work.
3).Is there anything that can be done about this, or is it entirely hardcoded, forcing me to keep the current approach despite the bloat?

Thank you very much Meridian for any insight.

3

OXCE Suggestions DONE / Re: [DONE][Suggestion] listOrder on Armors

« on: September 25, 2024, 07:16:36 pm »

Done.

Armors now also have listOrder.

The sorting is FIRST by armor storage item listOrder, and then SECOND by the armor listOrder (if the armor storage item listOrder is the same, or there is no armor storage item).

Simply wonderful, Thank you very much for fullfilling another request.

4

OXCE Suggestions DONE / Re: [DONE][Suggestion] Option to Define UFO Landing or Crashed Status in Mission Generator

« on: August 12, 2024, 06:55:09 pm »

Implemented as a small toggle button in the top-right corner, see screenshot.

Absolutely wonderful, i'll check it out when i get home later this day 

5

OXCE Suggestions DONE / Re: [Suggestion] Saving Inventory Loadouts in .rul Files

« on: August 12, 2024, 06:41:27 pm »

and when should the data be copied from *.rul into *sav ?

1. on new game?
2. on every load?
3. on hotkey?
4. something else?

TL;DR:
1. would be more convenient.
3. in case first option doesnt apply into the "new/quick battle" screen.


Long Answer:
If I'm completely honest, my preferred option would be the one that doesn't create an insurmountable hassle to implement. However, I'll leave that decision in your hands, as it's clear you're more knowledgeable about this topic than I am.

1. I think this option might be the most convenient for new players who try mods and find themselves overwhelmed by multiple new weapon additions. It could help mitigate the 'shock' of the sheer number of new options. For veteran players, or in my specific case, most of the time spent in the loadout screen is during the initial setup when creating templates. After that, I just replace weapons as new tiers are unlocked. The critical point, in my opinion, is at the very beginning.

2. I might be completely wrong, but wouldn't this create extra load time, especially in some mega-mods with hundreds of additions? It feels like a less convenient version of option 1, to be honest.

3. This could be an excellent tradeoff, with the added perk that players who create their own exotic loadouts based on their preferred playstyles won't have their lists cluttered with more 'standard and conservative' suggestions. Also, this is the only scenario I can imagine affecting the quick battle generator, right?"

6

Work In Progress / Re: [WIP] Xeno Operations LEGACY

« on: July 26, 2024, 07:26:50 pm »

Those are interesting maps, but what are you going to do with ufopedia craft art?

To be absolutely honest, I don't have the slightest idea. I'm not very skilled at creating large images, especially in the XCOM art style. The best I can do is mix and match some pictures and pass them through a filter to reduce the resolution, hopefully achieving the desired effect. Currently, I'm working on the Firefly image, but I don't want to spend too much time on it since I still have a lot of pending tasks.

[Spoiler]

7

OXCE Suggestions DONE / Re: [DONE][Suggestion] Image options for the Ufopaedia and armors

« on: July 26, 2024, 06:35:00 pm »

Hi, sorry for reviving this thread. I'm currently working on Xeno Operations and can explain the situation better, as what Alex_D is asking for is exactly what I need.

For context, in the mod, every Ufopaedia image has an intricate background. Therefore, something needed to be done to avoid the plain black background you get when you assign a Ufopaedia page to the armor.

Currently, this is achieved by adding a "dummy" version of the armor with the suffix "DISPLAY," which uses a special custom spriteinv. This sprite is manually created.

This is the REAL ARMOR

Code: [Select]

  - type: STR_FLIGHT_JUMPSUIT
    ufopediaType: STR_PILOT_UFOPEDIA_DISPLAY
    spriteSheet: XOPS_XCOM_0.PCK
    layersDefaultPrefix: HUMAN
    layersSpecificPrefix:
      8: FLIGHT_JUMPSUIT
    layersDefinition:
      M999: [this repeated a bunch of times, dont need to add it in this post]
    spriteFaceGroup: 6
    spriteFaceColor: &SpriteFaceColorAgent [same as above for this post]
    spriteHairGroup: 9
    spriteHairColor: &SpriteHairColorAgent [same as above]
    customArmorPreviewIndex: 0
    storeItem: STR_NONE
    loftempsSet: [ 3 ]
    corpseBattle:
      - STR_CORPSE_FLIGHT_JUMPSUIT
    frontArmor: 6
    sideArmor: 2
    rearArmor: 2
    underArmor: 2
    stats: &StatsForJumpsuit [avoided, same as above]
    damageModifier: &damageModifierJumpsuit [same as above]
    builtInWeapons:
      - STR_NULL_POCKET_LS
      - STR_NULL_POCKET_RS
      - STR_NULL_BACKPACK
      - STR_NULL_BELT
    units: &CompatibilityWithPilotUnits
      - STR_PILOT
This is the DUMMY

Code: [Select]

  - type: STR_PILOT_UFOPEDIA_DISPLAY
    spriteSheet: XCOM_0.PCK
    spriteInv: PILOTUFOPEDIA
    weight: 2
    loftempsSet: [ 3 ]
    frontArmor: 6
    sideArmor: 2
    rearArmor: 2
    underArmor: 2
    corpseBattle:
      - STR_CORPSE_FLIGHT_JUMPSUIT
    stats: *StatsForJumpsuit
    damageModifier: *damageModifierJumpsuit
- If I use the dummy, it shows as expected in the rest of the Ufopaedia [1].
- If I directly add the armor in the ufopedia.rul, it has a black background [2].
- I tried modifying the interfaces.rul to put a custom background by adding the tag "backgroundimage:" hoping to have the Ufopaedia article include that background and then display the unit paperdoll as it usually does, but this was not successful.

Code: [Select]

  - type: articleArmor
    backgroundImage: BACK08.SCR #same as weapons?, for testing
    elements:
      - id: button
        color: 239    # Blueish gray
      - id: text
        color: 8   # chalky
        color2: 71  # green
      - id: list
        color: 6   # grey
        color2: 71  # greenI wish it would work[3] like in the same manner like facility or weapons screens [4], as I already have the "empty" background image ready[5].
(regardless I still use typeufopaedia to signal which article the MMB should open when clicked for all color variants of the same armor).

My issues with the current problem:

Spoiler:

Even though I'm taking advantage of the nodes "&" and "*" to simplify the process of updating stats, I'm now working on adding extra versions of the armors intended for pilots. This requires me to add another EXTRA dummy armor for each one I create, and also a custom image for the specific armor. Due to the compound nature of this images, every little change or tweak I make to the paperdoll requires the whole spriteinv image to be redone entirely.

Expected benefits:

Spoiler:

Simplifying the process of creating new Ufopaedia armor articles with custom-made backgrounds would save me from all the extra work on images and reduce the amount of clutter and unnecessary bloat. In this specific example, around 15 dummy armor definitions and the images related to them would be eliminated. As I mentioned before, every time I change even a single bit, the spriteinv file must be redone to match both versions.

TL;DR:

Spoiler:

1).To have custom background images for the Ufopaedia armor articles, a duplicate dummy armor with a custom spriteinv is currently required.
2).Trying to change the background image associated with "type_id: 5 (armor)" inside the interfaces.rul "articleArmor" doesn't seem to work.
3).Is there anything that can be done about this, or is it entirely hardcoded, forcing me to keep the current approach despite the bloat?

Thank you very much Meridian for any insight.

8

Work In Progress / Re: [WIP] Xeno Operations LEGACY

« on: July 25, 2024, 01:04:23 am »

Hello again, everyone.

I want to dispel any concerns: I am still actively working on the mod. I haven’t updated anything recently because I have the bad habit of starting new features before finishing my current ones, which leads to a growing list of WIPs and half-baked additions im up to finish. I apologize for this, but if I don’t take advantage of the hyperfocus I get on new tasks, I don’t work as comfortably.

That being said, the last addition I made, which is finished, tested, and hopefully ironed out, is the rework of ALL transport ships. This patch started with small retouches to the Firefly, then evolved into a rehearsal and addition of a new ship. Now, I’ve finished retouching the entire line of transports, and I'm very satisfied with the results. Therefore, I don’t see any extra work needed in this area in the near future. So, expect to notice not only changes in appearance but also in functionality. Every ship will have a unique niche, maintaining their relevance even as new models become available. You'll find tools for different situations and different approaches:

Need to assault an enemy base and require heavy load hauling of troops and tanks? The Goliathus will help you with that. Need to respond to a sudden terror mission on the other side of the globe with a quick, elite yet small force? The Hercules will be perfect for it!. Meanwhile, Scarabs and Fireflies will remain your workhorses throughout the entire invasion, even into the mid-game.

With stats and layout changes, I hope you’ll find different options with interesting trade-offs so that progression feels less like a chore and avoids no-brainer situations where every new ship surpasses the previous one in every aspect. This is especially important given the semi-RNG mechanic the CODEX provides, to prevent situations where you heavily invest in a new plane only to have a better one become available shortly after.

On another topic, I’ll try to showcase the newest additions to the XCOM arsenal, which now include, to name a few examples, 8 melee weapons and three shields, 21 ordnance options (grenades, satchels, explosive blocks, breaching charges), and new additions to alien weaponry (I'm still learning how to apply them to alien deployments, though).

Thanks for your patience.

9

Tools / Re: LOFTEMPS Viewer 3D

« on: July 18, 2024, 07:29:41 am »

what's your operating system?

Oh, right, i forgot to put that.

Windows 11 Home, 64 bits

[Spoiler]

10

Tools / Re: LOFTEMPS Viewer 3D

« on: July 17, 2024, 08:43:41 pm »

Outstanding work! This tool seems incredibly useful, but I'm unable to run it properly. I selected the mapviewer folder correctly, as well as the mapblock and other necessary files, but when I click the run button, it simply freezes. The task manager shows a spike in CPU and RAM usage, but after a few seconds, the program closes itself. Any idea what could be happening?

I even tried deactivating the antivirus while running the executable, just in case, but to no avail.

I'm pretty sure my PC is beefy enough, so I don't think it's a specs issue.

Spoiler:

cpu amd 5600x, 32gb ram, gpu 6800xt (i dont think this requires this tho)

Thank you very much!

11

Work In Progress / Re: [WIP] Xeno Operations LEGACY

« on: June 06, 2024, 12:32:43 am »

Man, you have no idea how much i want that sweet xops armor and the tank update, principally the tank. Excellent work.

Thanks for your kind words, Getfreur. The update is coming along steadily and should be finished soon™. Most of the sprite work intended for this patch is nearly done. I'm still struggling to implement the dynamic sprite script (about 4/5 of the artwork is done), so I'm debating whether to include it now or save it for the next patch to avoid delaying this one further.

Hi there, I like your Scarab craft design which reminds me of Starship Troopers transport. There's some mismatch sprite align on the front. You might want to edit the craft sprites for perfect touch.
When I played your mod, there's some missing parts for the research: Plasma Projector, Cybernetic Soldier, Mind Probe (Which is not found in the Battlescape), Psi Lab, Psi Amplifier, Power suit, Flying Suit, Firestorm, and Avenger. You can add or edit to prevent players wasting time to research pointless items.

Ultrakiroxei, you're right about the Scarab being inspired by the Viking from Starship Troopers. I always dreamed of creating a plane as a homage to that ship, and I'm glad I tried. Regarding the mismatch, I think it's a coloring issue. The point is a different shade, making it stand out as an incorrect piece. I might need to revisit this sprite, but that kind of work will definitely be moved to the next patch. Thanks for the suggestion. You're correct about the errors in the current tree. I'm aware there are many misplaced elements. Expect a total revamp when the next patch goes live.



The bulk of the remaining work involves balancing issues and implementing the revamped research tree. I've done some testing, and the general ideas are mocked up. Now I need to clean up any stragglers and remove duplicated projects and dead-end researches. As Ultrakiroxei mentioned, there are several issues in the current tree. Addressing these issues was the main reason for this patch. Initially, it was meant to solve the research problems, but then I started adding new content and the tree got pushed to the back burner, lmao.

I can't promise an exact date, but I estimate the patch will be ready before the end of this month as I really need feedback on most of the changes. As a token of appreciation for anyone eagerly awaiting the new patch, here are some snippets of the extra work I've been doing:

12

Work In Progress / Re: [WIP] Xeno Operations LEGACY

« on: May 21, 2024, 09:06:21 pm »

### Development News Update ###

TL;DR: If you prefer to skip the detailed explanation, feel free to check the attached pictures and their descriptions. They should be (hopefully) self-explanatory.

Hi everyone!

As I mentioned previously, the next patch will come with significantly improved features. I wanted to showcase some of these updates while I continue to finish the remaining tasks.

I've completed the next tier for the second tier of armors [1]. I'm finally happy with the result, using parts from HALO REACH MOD and some original assets created by Hans Woofington. This new armor tier will have a different role. Being bulkier, it will significantly differ from the basic armor to avoid it becoming a no-brainer choice. This also extends the viability of the initial armor, which was saddening to see last less than a single month, especially after its previous visual upgrade. The pilot variant will receive a different chest piece and a unique helmet to further differentiate it. Additionally, to enhance the distinction [2], I've followed Neoworm's designs and changed the general color palette of pilots from blueish to scarlet red, similar to the PS1 version. With this change, the PS1 assets mod from N7kopper is now straightfoward compatible, coinciding with all the pilot-related cutscenes.

In the screenshot of the pilot[2], you'll notice new sprite work for some weapons. Some are new, and others are updates of previously available weapons. All melee weapons received an extra pass, so every tier now consists of a knife and a bigger blade of the equivalent technology. Some assets were borrowed and kitbashed from Woofington's assets. Alien blades received a new appearance inspired by shredder gauntlets/Yautja wrist blades from the Predator franchise.

Inspired by the demolition charge mod by DBarizo, I've introduced three breaching charges [2] to be used solely against UFO walls to create extra entrances and assault from more creative angles. These come in three varieties with increasing portability and reduced weight, although they function practically the same.

Next, we have the newest soldier type, the Tank Driver [3]. With the help of efrenspartano and using other mods as guidance (especially GWotW), I implemented the mechanic where tanks are "armors worn by specialized units." This system is simply better than the archaic and aging vanilla tanks system. Note that while the system is in place, the artwork is still placeholder as while I struggled to understand how it worked. A better sprite will come soon, with the drift suit based again on Neoworm's assets.

As an extra note, I managed to "smooth" the fur of dogs[4], making them look less pixelated. I can now create different fur patterns, so expect some variations in our four-legged friends' appearances. I'm also working on ideas related to them to add nuance to the mod's lore.

Additionally, I'm experimenting with a portable ballistic shield[5], thanks to efrenspartano's suggestions. I'm using the HALO REACH MOD kig-yar gauntlet shield script to simulate its functionality as an independent item that can be dropped, tossed, or exchanged between troops. There are three variants: XCOM basic ballistic, an Xelloy improved version, and an energy variant. The last two are functioning in-game, but their sprites are placeholders.

In other news, I found the master file that controls the palette and colors used for the interfaces, thanks again to efrenspartano. My plan is to unify all menus[6] and interfaces into a coherent and consistent theme. Currently, I've only changed the main menus[7] and the geoscape sidebar. I'll wait for feedback from you (readabilty?, pleasant color choice?, general thoughts) before investing more time into this change.

And finally, after some discussion, I decided to follow efrenspartano's advice and include the use of filipH's "ammo sprite scripts." The idea is that every weapon will have a series of different sprites that change based on ammo count[8] (empty mags), special ammo[9][10] type chambered (AP,HE,Standard,overcharged, etc), inventory status (grenades being primed/unprimed, swords being off in backpacks but glowing in hands of troopers), etc. While this requires extra work, it's worth the effort. I've already finished about one-third of the weapon tiers, and now the hard part is implementing the script correctly. My plan is to finish all sprite work within the next week before focusing on the ruleset.

That's all for today's showcase. Thank you for your patience, especially if you made it through my detailed post. Stay tuned for more updates and showcases in the coming days.

13

Brutal AI / Re: [SOLVED] Allow Reordering of Bases in Management Screen

« on: May 12, 2024, 08:19:09 pm »

I investigated.
The previous functionality of right-clicking on the list of bases was moved to middle-click by the contributor Flaubert when he implemented his "more than 8 bases"-feature.
Right-clicking now scrolls to the right or left if you have more than 8 and click the first or last base-slot on the list.

Thanks! , confirmed it works as intended.

14

Brutal AI / [BUG REPORT] Allow Reordering of Bases in Management Screen

« on: May 11, 2024, 07:49:57 pm »

In OXCE you can right-click selected base in a list of bases, to shift it left once. this feature seems to not been working in current BAI build 8.4.0.

 Thanks a lot for your hard work

15

OXCE Support / Re: [SOLVED] Allow Reordering of Bases in Management Screen

« on: May 11, 2024, 07:46:37 pm »

In OXCE you can right-click selected base in a list of bases, to shift it left once.

Thanks for the imput, noted!, i currently play using BAI-OXCE, i will report this in their subforum.