Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Anubis-class Cruiser (12/20/24)

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - xenoargh

Pages: [1] 2 3 ... 338
1
Quote
All I can say is it works in the use case the game uses it for, hmm.
Yeah, that area of the code is... interesting, lol. Okies, I'll test some things.

2
Has there been a change to Hull Mods in .variants?

I saw this stuff in the Automated XIV Legion's file:

Code
    "hullMods": [
        "automated",
        "missleracks",
        "targetingunit",
        "heavyarmor",
        "reinforcedhull",
        "degraded_engines",
        "faulty_grid",
        "comp_structure",
        "hardenedshieldemitter"
    ],
    "permaMods": [
        "automated",
        "degraded_engines",
        "faulty_grid",
        "comp_structure",
        "missleracks",
        "targetingunit",
        "heavyarmor"
    ],
    "sMods": [
        "missleracks",
        "targetingunit",
        "heavyarmor"
    ],

Here in testing, the S-Mods do not show up. There's also the "hardenedshieldemitter" that is the one Hull Mod not present in either of the other lists. IDK whether that was intentional.

3
General Discussion / Re: Destroyers
« on: August 01, 2023, 03:19:32 PM »
Part of what affects destroyer viability in vanilla are general game mechanics, such as the arbitrary fleet ship limit pushing you to get the best ship for every slot, the completely trivial economy that makes acquiring and running the most expensive ships a non-issue, the ease of reaching high burn levels even with larger ships and so on.

With all of these issues fixed destroyers regain more of a place, though they still need changes to fulfill a stronger role. In my custom build, mainline destroyers have by far the highest concentrated firepower for their size and have a higher speed advantage over cruisers, making them a source of flanking firepower that is not easily overshadowed by frigates. Not all DDs have these characteristics, the Enforcer remains mostly an escort for larger ships and the Manticore sits as a force multiplier for smaller and faster destroyer fleets for instance - something that is now valued because high burn levels are no longer a given.

^ This. All that.

Plus, I have Destroyers that are meant really specifically to be OP-in-player-hands endgame ships... as mobile, glass-cannon assassins. Because Destroyers really can have a really interesting sweet spot where they get clobbered if deployed as a monofleet against the giant deadly endgame ships, but can offer up cheap-but-deadly support, Frigate-killing and Flux erosion service all the way up to endgame... if there aren't so many things in the game design working against them, starting with their cost-effectiveness vs. something larger. I actually have more problems atm in my private build of Rebal making sure all the Cruisers are passable for what they cost rather than most of the DDs, which is where I feel things should be.

4
Suggestions / Please Change How Skins Are Handled, and How They Crash
« on: August 01, 2023, 03:10:15 PM »
These are quality-of-life issues, from a modding perspective.

1. Right now... Skins are referred to, in Variants. But they aren't referred to with a unique identifier (say, "skinId"). Instead, they're using "hullId". But they're not actually referring to a proper Hull ID string from ship_data.csv and they're not referring to the hullId string in a .ship file.

This isn't ideal; something like that in the JSON files should be unique, imo, so that there's no situation where, say, code reading JSONs encounters a "hullId" that leads to a null or other such issues. If "skinId" is "" (the default value) then the variant should be using baseHullID, obviously.

I realize, that for regular modding, getting baseHullID is a thing, but there are other situations where this can create some extra complexity, and I think this might help you keep .skin / .variant more-maintainable as well.

2. Can you spend a little time on the crashy-crashy behaviors with Skins?

For example... the falcon_p is one of many situations where the engine crashes in most-unhelpful ways atm:

A. For example, this line:

"removeWeaponSlots":["WS 003","WS 004"],         # ids

If either "WS 003" or "WS 004" aren't present in the .ship file, the engine crashes and produces an unhelpful error message.

B. Same thing happens here with this data:

"weaponSlotChanges":{
        "WS 005":{
            #"angle": 0,
            #"arc": 210,
            #"mount": "TURRET",
            #"size": "SMALL",
            "type": "COMPOSITE"
        },
        "WS 006":{
            #"angle": 0,
            #"arc": 210,
            #"mount": "TURRET",
            #"size": "SMALL",
            "type": "COMPOSITE"
        },
        "WS 007":{
            #"angle": 0,
            #"arc": 210,
            #"mount": "TURRET",
            #"size": "SMALL",
            "type": "MISSILE"
        },
        "WS 008":{
            #"angle": 0,
            #"arc": 210,
            #"mount": "TURRET",
            #"size": "SMALL",
            "type": "MISSILE"
        },
    },

...it's also not really clear what, exactly, is happening w/ the commented out data there, but I presume that all that's occurring is an override of the Weapon Slot's type.

This isn't the only example of screwy behavior with Skins, but it's one of the areas where users can create situations where the engine crashes, but it's unclear why. If nothing else, a "was attempting to parse Skin <skin id> and failed to load, crashing now, kthxbye" would be better than what it does now, because then the user knows where things went horribly wrong.

5
Suggestions / Re: Tradução PT-BR
« on: July 25, 2023, 02:10:20 PM »
Practically all of the English text is now readily accessible for machine translation at this time. See starsector-core/data/strings for the relevant text files, which are in JSON and CSV formats.

6
Right. It's a bigger ask, though, since that UI is almost certainly Very Hard Coded Indeed and this is in the "nice to have" category. The other stuff, like saving the variant in a slightly-more-useful-way-name-wise, or having that UI poll the saves/missions/mission_name file for saved .variants, see if any match <id> and then, if true, and a slot remains, populate next free slot with <variant>, shouldn't be too bad?

The OP thing could just be a config flag, I'd think. It's kind of like how SSED won't let you edit in more than the base level of Vents and Caps, even though going over has been an in-game convention for many years now.

7
This is a minor thing, given that Missions are meant to be the "training wheels", but when I have four Wolfs I want to equip with <test configurations> in a Mission, it'd be nice if:

1. You could really save the Variants and pass that along to other ships in the Mission. IDK whether Missions don't actually create a CampaignFleetAPI object or what, but you can't do it; save a Variant, and click on another ship of <type>, and you cannot see the saved Variant. Variants made in Missions are now built as files in /saves/missions (which is great) but they aren't labeled via the convention id_plus_variantname_with_underscores_instead_of_spaces.variant, which is a minor quirk that ideally would get fixed, because then we could do one and drag-and-drop straight into a mod, etc.

2. It'd be nice to be able to go over base OP limits in Missions to test optimized builds, mainly to test AI-built campaign stuff.

3. I know this is an unlikely ask, but the four-Variant limit, where if there are more than four, they simply cannot be seen / used, feels limiting sometimes. It'd be cool if that was a sliding list you could scroll through. This effects Campaign as well as Missions.

8
I like this general idea.

I also want to be able to control side-strafe as a separate value to forward acceleration, both for Systems and Hull Mods.

9
General Discussion / Re: This Forum's Stance on AI-Generated Content
« on: July 24, 2023, 05:22:24 PM »
Sorry. I thought that was relevant, as doing a LoRA with a mod's content now seems like a pretty dubious proposition from where I sit, unless it's very large and consistently styled. Nobody's going to clone BRDY's brilliant pixel-art tricks or MShadowy's flowing style with ease, I think. That's a bit of a relief, really.

Quote
I have seen mods for bannerlord, skyrim and even Rimworld with integrated chatbots as in either a commentator or actual npcs having conversations about the world or their created character.
That's really cool. I've written several things that hook into LLMs, and, with appropriate training, this kind of thing's quite practical. Using ChatGPT, not so much, mainly because it was a mod and it took off, you'd be on the hook for the Azure Cloud fees (it costs ~3X the cost of a web-search hit to query ChatGPT atm). But there are now several "wild" LLMs that can be integrated into software and run locally. Anyhow, I'll bow out of this discussion, as this is also kind of a derail.

10
General Discussion / Re: This Forum's Stance on AI-Generated Content
« on: July 24, 2023, 08:59:53 AM »
I'm just exploring the practical ramifications of the LoRAs here.

Like, is this EZ Infringement, even with a low sample size, or not?

My vote thus far is "no", but I've only been using Stable Diffusion for a few months. With the ones on the far right, I could fix them to be... OK, after post.

But it isn't no-skill work; David's color grading and contrasts are wildly different, for example, and there's nothing like his brushwork in these. And ofc, it goes without saying... but to get this many "OK, I guess" attempts at copycats, I had to run SD quite a few times; this was after setting up maybe a dozen runs last night with different parameters. It would've taken me less time to attempt a copycat by hand.

Anyhow, no, I'm not going to put out a SS portrait pack using this, period. While I'm not convinced this is actually infringing, I'm also not in favor of "anything goes" for this kind of thing, largely because I think it'll eventually devolve into people fighting about it. I will not be training any LoRAs on anything remotely SS-related, and the ones I've been using are made in a way that's actually pretty ethical, so far as I can determine.

11
General Discussion / Re: This Forum's Stance on AI-Generated Content
« on: July 24, 2023, 08:35:55 AM »
FWIW, I've just tried one of the LoRAs out, and have yet to have something pop out that was anything like as good as I'd have gotten from img2img plus a prompt.

The resemblance to David's work is... eh, let's say it's not very clear. However this was trained, it produced really samey results left to its own devices.


Left four is the portrait LoRA, just text prompts. Note that they all feel like clones. Center left is just me using one of the usual suspects, no img2img to guide things or postwork to fix framing. Right of center is David's work. Right four are both with and without the LoRA, but using two of the game's portraits as img2img base files. Note how they're suddenly very similar... but they still don't have the right feel. If I don't tell you which one's using the LoRA, I don't think you'd be able to guess.

They still don't look much like David's work to me. Maybe somebody better at this could get closer, or with a better img2img base emphasizing where to go.

A lot of the samey look in the first four is the low sample numbers; there are literally zero blonde men with beards wearing helmets in the SS portraits, which is why I picked that prompt out. The second set obviously has problems with framing; that might or might not be correctable w/ prompts, or simply running sheer numbers. But it's missing all of the warmth of David's work. The last four (again, the far-right set) are close on things like the eyes, but are missing a lot of other things. Could these be fixed in post to look like reasonable facsimiles? Probably, but this wasn't like doing photocopies, not by a long shot.

12
General Discussion / Re: This Forum's Stance on AI-Generated Content
« on: July 23, 2023, 06:40:16 PM »
True. Every time I fire up Easy Diffusion, it has new features. This week they added multi-LoRA. Totally fun.

13
General Discussion / Re: This Forum's Stance on AI-Generated Content
« on: July 23, 2023, 05:17:06 PM »
OIC. You could actually do a LoRA that worked with that many samples. Barely, but.

Fair enough, lol. I'm really surprised anybody bothered, tbh. 32GB of RAM on a GPU isn't exactly common yet, outside really expensive stuff, so... you're saying somebody did that on a CPU? That must have taken foooooorever, lol.

You'd think with all the cool things you can get the tools to do, and the unlikelihood of getting decent results with low samples, why bother. I guess some people just had to find out, lol. Anyhow, fine, I don't need to hear about it and I agree that's not cool.

14
General Discussion / Re: This Forum's Stance on AI-Generated Content
« on: July 23, 2023, 04:59:32 PM »
I guess the next logical progression of that question would be in regards to re-use of AI generated assets?  While it is hard for AI to mimic some particular person's style without feeding it a lot of samples, if AI generated art becomes the norm rather than the exception, it is very trivial for the same AI to generate more art similar to that originally generated if you've got the prompt and seed.  Reuse of similar AI generated images presumably wouldn't be a problem?  Likely not a problem for sprite ships, but it might be an issue for backgrounds and portraits.
Unless people are required to give the full prompts, seeds, number generators, etc. (which, frankly, is a bit burdensome and probably won't happen routinely) it's more likely that people will feed in existing images as img2img prompts and try to get "like that", I'd think?

In which case, it's back to, "is it clearly infringing?". I'd think that, for things like portraits and backgrounds, the results will be different-enough that it's a non-issue, unless it's kept so restrained re: prompt strength (essentially, how much noise is injected at the start) that it's 95% the same or better (and it'll be obviously a copy at that point).

This has indeed happened already, I have seen them.
Really? Who and how? Is this some Discord stuff that happened off-Forum? Or did I just miss it? I'm curious now, lol. If you just don't want to talk about it because it happened off-Forum, fine, but I didn't think anybody had the equipment, time or boredom required.


Quote
I *think* some courts have specifically said that AI output can't be copyrighted? So whatever came out of someone's prompt is not "theirs" in any real sense. I'm not 100% on this but that's my understanding. If that's correct, then reuse would be totally fine.
Actually, it's more complicated. The Copyright Office thinks that stuff like img2img works are probably copyrightable, but text-prompts aren't, unless they're incorporated into a larger creative work. Threshold appears to be "amount artist was involved directly with the creation". Fuzzy.

It's something that'll get tested in court a few dozen times over the next few years, to be sure.

15
General Discussion / Re: This Forum's Stance on AI-Generated Content
« on: July 23, 2023, 04:34:20 PM »
Quote
In the same vein, is training a model (eg a SD checkpoint) on other modders' work without permission and releasing the output allowed? This has happened a few times already.
So far as I'm aware, this isn't terribly practical or likely to come up, because even building a basic LoRA that might produce "somewhat like" work takes quite a few images to even get within spitting distance. I think most of the people here don't know how hard that actually is. For the record, I've been completely uninterested in trying that; doing Dreambooth training just sounds like work.

But I'm with Alex; if it's done, and it's clearly infringing, they should be gone. I think we're all agreed on this.

Pages: [1] 2 3 ... 338