Messages

1

The X-Com Files / Re: The X-Com Files - 3.5: Whispers In The Dark

« on: November 20, 2024, 07:02:34 pm »

It looks like it was unintentionally packed into a subfolder. Just extract the folders within 'pakowanie' and it'll work. But yes, it'll be probably wise to repackage it without that folder.

2

The X-Com Files / Re: Bugs, crashes, typos & bad taste

« on: November 18, 2024, 05:23:39 pm »

Currently it's a bit of a contradiction, it's first stating there's no power supply (or source) but then states it uses an external one.

"With no power source found on the turret, it relies on an external power supply." is my suggestion.

3

Help / Re: help with the " Supressed Error for 'Mod': Obsolete "

« on: November 15, 2024, 03:57:41 am »

Ok, had to turn verbose logging on to find it. It's not line 1388, but 1380 on my end, the very last item at the end of the eldar.rul file, you have a 'type' node definition for AUX_ELDAR_KIT but it's under the 'soldierTransformation' ruleset which uses 'name' node definitions. This is causing a false flag with the 'supressed error' but still something you probably want to fix either way.

4

Help / Re: help with the " Supressed Error for 'Mod': Obsolete "

« on: November 15, 2024, 12:34:21 am »

Yes, basically those nodes should be updated to use the 'ignore' node type rather than not having one defined. It's a change that can be done now and will work with the latest release (and some previous ones). If not, after a future update up to the devs, those 'bad' nodes will cause an error rather than a warning suppressed error. Since this is usually tied with OXCE yaml anchor copy pasting, searching for any of the & tags can help locate them, however, not all '&' will be bad, just those without a the typical "type" node or one of the extended ones (including "ignore")

Edit:
This regular expression has worked for me to pinpoint 'bad' nodes in VSC. It covers the common node names but none of the extended ones. This merely means that some false positives might occur if the mod uses any of the extended nodes.

Code: [Select]

(- &.*\n)((?!type|name|id).)*$
Edit 2:
Tested it with Rosigma, but the only 2 flags aren't related to that line number.
The 1st one points to armors_IG line 2618: This one I'm not sure about since there is a 'type' node, just 3 lines down from it.
The 2nd one points to armors_PRIMARIS line 109: Again, 'type' is used, this time 4 lines down.

Now I'm really curious how that line that is triggering the suppressed error is defined.

5

OXCE Suggestions NEW / Re: [Suggestion] Submodding "composite" data fields by their individual components

« on: November 04, 2024, 10:31:02 pm »

Just tested this

Code: [Select]

  - type: STR_MONSTER_VS_MOB_JUNGLE
    briefing:
      music: DW_SHOCK
and yup, that's exactly the cause.

6

OXCE Suggestions NEW / Re: [Suggestion] Submodding "composite" data fields by their individual components

« on: November 04, 2024, 08:53:55 pm »

For what it's worth, loading the save in XCF 3.4.1 yields these screens. First one from the 'details' button when clicking on the site, 2nd from Osprey landing at the site.

Will check the github repo and see if I can spot anything.

Edit:
Downloaded all the files from the repo for the in progress 3.5 and I am unable to replicate the issue. It appears to be some missing string from the screenshot, but both US english and UK english work fine and it doesn't explain the different background image. Does the openxcom.log file show any issues that could be connected to this?

If you're using a local copy of the rulesets, perhaps check indentantion in alienDeployment.rul, it seems to be using default values for the background (BACK16.SCR) and the description string is using alienDeployment + _BRIEFING when it should be using STR_MONSTER_VS_MOB_BRIEFING as per what I see in the ruleset.

7

Help / Re: New to modding & questions

« on: November 04, 2024, 06:31:52 pm »

While not a variable, you could get a very close aproximation of this via dummy research topics. Soldiers, scientists, engineers, gear and facilities can be made dependant on a topic before you can hire, build, purchase or manufacture any of them. However, I don't believe there's a way to prevent a player from sacking, selling or dismantling. Unlocking the dummy topics can be done either via completing a particular mission or events popping up.

A sample of this would be

Code: [Select]

research:
  - name: STR_DUMMY # This one must never be unlocked
    dependencies:
      - STR_DUMMY
  - name: STR_SC1 # First security clearence obtained
    dependencies:
      - STR_DUMMY

hireEngineersUnlockResearch: STR_SC1
hireScientistsUnlockResearch: STR_SC1

soldiers:
  - type: STR_SOLDIER
    # ... other fields in the definition
    requires:
      - STR_SC1

facilities:
  - type: STR_LIVING_QUARTERS
    # ... other fields in the definition
    requires:
      - STR_SC1

# Event that unlocks 1st security clearence. This can be used in monthly event triggers or from alien deployments (completing a mission).
events:
  - name: STR_SC1_EVENT
    # ... other fields in the definition
    researchList:
      - STR_SC1


Replacement of soldiers and gear seems a bit trickier as it's possible to base events on a soldierType present (or not) but not on soldier count. The same goes for gear (or items I should say) and it only looks what's in the base stores, not in the craft. You may have to base the triggers of these on monthly scoring and possibly have to define them per difficulty.

8

The X-Com Files / Re: Bugs, crashes, typos & bad taste

« on: October 28, 2024, 05:50:54 pm »

I think I need some background, correct me anywhere that I'm wrong. By what I've read in the different exalt articles that mention it, I take it that the aliens are providing intentionally "defective" psiclones that do work or barely work, and require frequent replacement via different means (they create an addiction and/or they breakdown relatively soon, etc). Once XCOM becomes aware of this and understands how the devices work it can then provide a fully functional Psiclone that neither requires replacement nor produces an addiction. Is this the gist of what you're trying to describe in the article?

9

The X-Com Files / Re: Bugs, crashes, typos & bad taste

« on: October 27, 2024, 01:27:41 pm »

It's not a typo, nor gramatical or even syntactical issue, it's more a lack on sensical meaning, the "but" would indicate some exception to the cracked version vs the original psiclone, so saying that it's "but functioning" you're implying that the original is "non-functioning". Without a clarification of what the intended text is suppose to inform the reader of, it's not easy to propose a solution. Even if we change the "but" with "yet" the same issue remains, it still tries to inform about an exception of what it does (doesn't) that the original doesn't (does).

On a side note, since I read the whole text. The part that starts as "We can now understand..." can be rewritten as "We now understand how Psiclone works well enough..."
- "Can" is simply unnecessary
- "The" is a nightmare to handle when dealing with proper nouns. For example, it's used when referring to names of rivers, seas and oceans, but NOT when used with names of lakes or mounts and then you do use it again with mountain ranges. However, in this case I see it used in a similar manner as drug names, they don't use the article "the". Additionally, sometimes you case use the article with proper nouns that don't normally use it for an emphasis effect.

10

OXCE Suggestions NEW / Re: [Suggestion] Option to disable spotters spotting when hit

« on: October 26, 2024, 02:46:48 pm »

How about exposing getTurnsLeftSpottedForSnipers and setTurnsLeftSpottedForSnipers in Y-scripts the same way getTurnsSinceSpotted and setTurnsSinceSpotted are instead? I already have an idea of a sample script that could handle this "issue", but it's currently not possible without these operations.

11

Troubleshooting / Re: Switches to change resolution disappeared

« on: October 13, 2024, 09:08:27 pm »

AFAIK, this is related the display filter currently used. "Disabled" or any other filter that doesn't end with an asterisk (*) won't have the arrows to change the resolution that way, those that do have the asterisk will. You can still change each parameter individually on the resolution if you click on either the current width or length values.

12

OXCE Support / Re: Help create a mission from the base

« on: October 09, 2024, 05:05:35 pm »

By default, all missions start from space, even base generated ones. If you want it to start from a base you'll need to specify an operationType in the alienMission itself. You probably should check out this particular thread about the topic here (https://openxcom.org/forum/index.php/topic,6557.msg104669.html#msg104669). Note that if in the example code provided by Kozinsky you also update the mission for STR_ALIEN_HARVEST to use, let's say:

Code: [Select]

alienMissions:
  - update: STR_ALIEN_HARVEST
    operationType: 1
It will work, but now, ALL of these instances of the mission will be earth-based ONLY and in this particular example case, require at least 1 alien base present in the region to function or it will be aborted. If your idea is to have bases generate already defined missions but not alter the vanilla "from space" behaviour, you'll have to duplicate those missions to a different name (STR_ALIEN_HARVEST_FROM_BASE for example) and give them an operationType. Also, depending on the type you specify, you might have to set other properties too, all of that is explained in the thread linked earlier.

13

Troubleshooting / Re: 40K mod not appearing

« on: October 09, 2024, 04:40:11 pm »

Even if you don't observe anything in the log yourself, it's still a good idea to provide it as other eyes might be able to spot an issue that you didn't recognize. Anyways, I didn't notice this before, but this has been posted in the OXC related forums, both of these mods are OXCE ONLY and people that could help might not notice the post until much later. Back on topic, a copy of the log can shed some light on what's happening. What about other master mods, do those appear? If you go into Options>Folders and click on the path of the 3rd option, "User folder" it should open a folder where another folder called 'mods' is, inside that last folder is where your mods should be found, if not, then you've misplaced them.

14

The X-Com Files / Re: Bugs, crashes, typos & bad taste

« on: October 02, 2024, 04:26:59 pm »

Apparently I missed mentioning the script issue in ALIENBIGBASEGROWN is also present in ALIENBIGBASEGROWNHANGAR. Since they're essentially the same script just with the added map size (from the deployment) and main hangar mapBlock, the script fixes are the same. And because they share the same mapBlocks, the fixes for the particular issues with the connector mapBlocks are already in place.

15

Help / Re: A visual error that makes me feel quite blue...

« on: September 27, 2024, 11:57:54 pm »

You might want to provide other details, like if your mod is a submod to another and which one it is, for example. What I can spot so far is an incorrect way of adding HANDOB sprites:

Code: [Select]

  - type: HANDOB.PCK
    height: 40
    width: 256
    subX: 32
    subY: 40
    files:
      2801: Resources/CHEMLASERS/Chem_Laser_Rifle_H.png       
      2802: Resources/CHEMLASERS/Chem_Laser_SMG_H.png   
      2803: Resources/CHEMLASERS/Chem_Laser_Sawed_Off_Shotgun_H.png       
      2804: Resources/CHEMLASERS/Chem_Laser_Shotgun_H.png           
      2805: Resources/CHEMLASERS/Chem_Laser_Sniper_Rifle_H.png   
      2806: Resources/CHEMLASERS/Flash_In_The_Pan_H.png       
      2807: Resources/CHEMLASERS/Chem_Laser_Cannon_Hand.png     
      2808: Resources/CHEMLASERS/Chem_Laser_Machine_Gun_Hand.png             
The file numbering needs to change in increments of 8 as each handob png is subdivided into 8 sprites. The engine will load the 1st sprite into the index you've specified and incrementally add the rest for that weapon. The way you're doing it here, you are accidentally replacing each facing for the Chem Laser Rifle to the 1st image of each png of all the others, resulting in what I'll call, a weapon discoball, that will change depending on facing. Also, while it't not sctrictly necessary by what I've seen in other mods, I would recommend always using indexes that are multiples of 8 for handobs, like this:

Code: [Select]

    files:
      2800: Resources/CHEMLASERS/Chem_Laser_Rifle_H.png       
      2808: Resources/CHEMLASERS/Chem_Laser_SMG_H.png   
      2816: Resources/CHEMLASERS/Chem_Laser_Sawed_Off_Shotgun_H.png       
      2824: Resources/CHEMLASERS/Chem_Laser_Shotgun_H.png           
      2832: Resources/CHEMLASERS/Chem_Laser_Sniper_Rifle_H.png   
      2840: Resources/CHEMLASERS/Flash_In_The_Pan_H.png       
      2848: Resources/CHEMLASERS/Chem_Laser_Cannon_Hand.png     
      2856: Resources/CHEMLASERS/Chem_Laser_Machine_Gun_Hand.png             
You will also have to correct the handSprite to point to the correct index with this change. Note that since I have no idea what other mods you're using, I can't guarantee that the indexes provided in the example aren't being used by somthing else and you'll have to check that yourself.