Solar's wishlist

[Meridian]

Meridian, can I add an item to the random loot list several times, to make it appear more frequently?

Yes.

[Dioxine]

We can do anything we like. Just tell me.

Well, I'm not very tied up to the concept of bravery increasing in 10s only, but it needs to be consistent - either we have Bravery increasing just like any other stat, or not. If the interceptions can raise it by 1, then everything else (Bravery training from weapons, from resisting Panic) should be raising it by a non-10 number as well.

[Meridian]

OK, I'll change it to +10 then.

[Stoddard]

Digging around geoscape code I had an idea come up:

Make craft repair, rearm, refuel manufacturing jobs, if a craft has 'runts required' attr, which tell how many runts are required to attain the stock repair, etc speed. Since there's crew unification proposal listed in the wishlist, make this number equal to crew number, so that the crew has some work to do after a flight. Ofc if someone got wounded, you either have spare hands on the base, or the craft isn't getting ready in time.

Add some runt space in the hangars which enables these task types. Autogenerate tasks upon arrival to cut down clicks. To be extra nasty, disallow repairs without workshop-type space, maybe for severe damage only. Maybe fuel repairs with some kind of 'spare parts' item or just plastasteel/electronics/chemicals/scrap/booze.

Now I'm not sure if there's support to locking down runt space to be used for only one class of work. I think not, but on the other hand, each hangar will provide  IIRC at most 6 runt slots, so it wouldn't blow up total runt space much. Ofc if you squat this  space for other manufacturing, craft isn't getting serviced either. Could be used for "prisoner processing" and "employment interviews" on outpost-style bases that lack other runt space.

I'd write this myself, but I don't have time right now, neck deep in AI API. So I'm just posting this here to not forget it.

[Meridian]

As I said in the second post, I don't like Solar's "crew unification" proposal ("everybody can do everything"), I won't be implementing that. We'd have a completely different game if we did that.

As for your proposal:
 - repairing/rearming/refueling craft by actual manufacture jobs seems like micromanagement hell to me
 - what I would probably consider acceptable (for me) is having a possibility (not necessity) to assign engineers to repair manufacture project (or any other blocking task, doesn't have to be via manufacture GUI) to help speed up the repairs; I wouldn't touch rearm and refuel as they can't be sped up as far I understand

[Dioxine]

If we want to do anything here, there should be an option to add 'ground crew' to a craft, up to 20 Runts maybe?
0 Runts: 25% repair speed (chance to repair per hour), no refuel, no rearm
Each extra Runt: +7.5% repair speed (up to 150% repair speed at 20 Runts).
3 Runts minimum always required to rearm and refuel craft? (so the real min. repair speed is around 50%); these Runts are assigned automatically & required to keep the craft running (in other words, can't build/buy/move a craft if 'Not Enough Runts Available For Ground Crew').
This should be done by a separate UI in the craft, & has nothing to do with Workshops at all. Presence of Runts is all that's required. Such runts are unavailable for manufacturing.
I know this is a little complicated but frankly, I'd hate to see ground crew roles relegated to some Workshop project; it's just not the right place. Adding Runt Space for hangars to patch it up is also bad IMO, as it will confuse the game as if it should show Workshops, or Vessels on R-Click.
With my solution, a single Outpost could service up to 3 Hangars (barely), but no Soldiers... Ugh, adding pilots into the equation, 2 crafts for Outpost seems like maximum realistic capacity. But that's just an Outpost!

This solution also goes towards my vision of bases requiring actual support personnel (or at least unoccupied Soldiers) for tasks like watching radars or manning turrets

[Meridian]

Now, that's more like it.

It can be nicely optional, fine-tuned via rulesets and compatible with vanilla. It scales, but doesn't overscale. It doesn't pollute manufacturing either.

I'd scale the repair speed a bit differently, but that's just a minor thing.

One thing that doesn't work well here (considering how runts are used at the moment), is the automatic assignment of runts. For 99.999% of the time you will have no free runts at the base. All will be either doing something you need or working their asses off for dolaros in the workshops (unless you play badly). Maybe we can do something about that, maybe not.

[Dioxine]

I think the function is more or less fine. It accounts for diminishing returns just fine. However it caps max ground crew at 4x min; I'd rather go for x5...x8 (with maybe 65% repair rate at min crew, 200% at max). Unless I'm reading it wrong.


EDIT:
Also, important lore fact: all hulls are self-regenerating so some base repair, even at 0 ground crew, should be going on.

Also I don't know what's worse; getting messages that the craft requires some min ground crew, or removing min crew requirement altogether and getting messages that the craft cannot be reloaded/refuelled due to the lack of it.

[Surrealistik]

That sure looks familiar:

Being able to allocate Runts to expedite craft repair might be a good idea; if you need to limit the rapidity of repairs and the opportunity cost of not manufacturing goods with those Runts is thought to be an inadequate limiter by itself, merely cap the number of Runts that can work on each ship.

[Meridian]

Yes, and that's the reason why new ideas should go to new threads
To be honest, "Suggestions on how to improve the mod" thread should have been closed long ago... nobody can track that... well, I can't.

[Dioxine]

That sure looks familiar:

You weren't the first guy here to come up with this, sorry for raining on your parade.

[Surrealistik]

You weren't the first guy here to come up with this, sorry for raining on your parade.

Well if so, I didn't see it (like some of the others in this thread evidently). Either way that I'm not some kind of idea pioneer on the subject per your claim is not something I'm distraught over. It's simply a feature I would have liked to have noted more interest in earlier, especially with pre-Crab repair times being such a PITA.

[Dioxine]

If you really have to know, it wasn't worth commenting for the dual-pronged reasons of being a well-known improvement idea, and the reality that it needed an attention of a coder to happen (which just happened).

[Surrealistik]

If you really have to know, it wasn't worth commenting for the dual-pronged reasons of being a well-known improvement idea, and the reality that it needed an attention of a coder to happen (which just happened).

I didn't specify anything about having to know why the suggestion wasn't acknowledged; posts get missed or overlooked; that's not something I'm concerned with so much as the absence of implementation.

[Meridian]

Melee terrain damage

OK, so "simple" bullet tracing (even with several different trajectories) didn't work well.

I will try more complicated rules, depending on:
a/ direction you are facing
b/ elevation
c/ actual presence of an object (west wall, north wall, object or floor)
d/ plus a few selected trajectories (or better said only target voxels, even without LoF in some corner cases) per above hopefully covering majority of normal-shape walls and objects

Attached are the targeted objects in order per case.
The diagonal objects may be obscured by far walls, in which case (very rarely) they wouldn't be destroyed.

0 = N  = up-right   ... 1. north wall (origin tile), 2. object (from tile in front of you)
1 = NE = right      ... 1. west wall (from right-hand tile), 2. north wall (origin tile), 3. object (from diagonal tile in front of you), unless blocked by 2 other unreachable walls?
2 = E  = down-right ... 1. west wall (from tile in front of you), 2. object (from tile in front of you)
3 = SE = down       ... 1. north wall (from right-hand tile), 2. west wall (from left-hand tile), 3. object (from diagonal tile in front of you), unless blocked by 2 other unreachable walls?

4 = S  = down-left  ... 1. north wall (from tile in front of you), 2. object (from tile in front of you)
5 = SW = left       ... 1. west wall (origin tile), 2. north wall (from left-hand tile), 3. object (from diagonal tile in front of you), unless blocked by 2 other unreachable walls?
6 = W  = up-left    ... 1. west wall (origin tile), 2. object (from tile in front of you)
7 = NW = up         ... 1. north wall (origin tile), 2. west wall (origin tile), 3. object (from diagonal tile in front of you), unless blocked by 2 other unreachable walls?

Floors will be completely ignored.

For elevation 0-11 (maybe 0-9 ? or maybe 0-X ?) the current-Z-level tiles are considered.
For elevation 12-23 (maybe 10-23 ? or maybe (X+1)-23 ?) the tiles one level higher are considered.

X could represent "chest/arms level", something like unitStandingHeight-8 resp. unitKneelHeight-8.
Probably best whatever is used for bullet LoF check.