Subset Games Forum

Estel wrote:

7636kei wrote:Versioning that go 1.10 from 1.9 isn't quite unheard of. And that might be the next version they're going to, depending on how they number their version

I am relatively certain that bunch of our favorite FTL modders/mod tools creators are competent enough for being able to *properly* count from 1 to 10. So, I assume that such blasphemy won't fall upon us, now or ever. Delicious Friend.
(seriously though, I know such things happen, but versioning like that, from x.10 to x.9 is literally dumbest practice that may happen, breaking everything, from auto-sorting to update scripts).

wait, what?

7636kei didn't say x.10 to x.9, they said the opposite, "go 1.10 from 1.9"... in other words, from 1.9 to 1.10. yeah going from x.10 to x.9 makes no sense, especially considering we're currently on v1.9.1

You're right, I apparently can't read Or spend too much time debugging versioning problems in debian repos. Either way, i stand corrected and edited my post

I wanted to bring up this issue for quite a while, but I haven't gotten around to it back then.

When I used the "mod:findComposite" tag, I decided to used the AND logic in order to provide compatibility (or additional stuff) across Total Conversion mods. Unfortunately, it doesn't seem to work.
Example:


I am I not using the AND logic right, or is this an issue?

FearTheBlaziken wrote:I am I not using the AND logic right, or is this an issue?

"readme_modders.txt" on findComposite:

Collates results from several <find...> criteria, or even multiple nested <par>entheses. The <par> combines results using "OR" (union) or "AND" (intersection) logic.

So what you've done is combine two finds (the last top-level weaponBlueprint named "MISSILES_MEGA") and (the last top-level shipBlueprint named "PLAYER_SHIP_HARD"). Taking the intersection yields nothing (being both this AND that), since those are mutually exclusive criteria. Had there been any viable results, you would've performed an action on each: appending <sMID/>.

I don't think there's a way to test an unrelated blueprint as a condition to edit a ship. Find tags check immediate children to drill down and act on results. Idle thought: the invisible root tag has both of those top-level tags as children, but the place you find *from* isn't itself checked, so you couldn't combine two findWithChildLikes to go nowhere from the root tag. And there's no <mod:findParent> to drill back up - after arriving at the unrelated blueprint, to bounce over to the ship.

Can someone send me a mediafire link to SMM because the current one doesn't seem to be working

gplay213 wrote:Can someone send me a mediafire link to SMM because the current one doesn't seem to be working

Download links in the OP ought to take you to SourceForge with a 5 sec sountdown.

If you're not prompted to save somewhere, that page has a "Problems Downloading?" button that offers a direct link (click & save immediately) and alternative mirrors.

After switching to new CLI parser, how to tell modman cli to restore vanilla FTL without apply mods?
In old modman there was modman -patch (without other params).
But new cli parser throws exception if no mods specified:

Is it a bug?

Update:
Created pull request with fix for this bug: https://github.com/Vhati/Slipstream-Mod-Manager/pull/14

SagePtr wrote:After switching to new CLI parser, how to tell modman cli to restore vanilla FTL without mods?

Is it a bug?

Indeed, it is.
Thanks!

Hello Folks,

I am trying to create an German Language Mod but the game doesn´t view the "Ä","Ü","Ö", letters, is there a way how I could solve the Problem?

You must create custom fonts with these letters. I made fonts with Cyrillic support using this tool: https://github.com/D-side/ftl_font