Topics

1

OXCE Suggestions Y-script / [Suggestion] Ability to BLIT objects by script.

« on: March 18, 2023, 06:18:11 pm »

This is a kind of big one, but it feels like it has a lot of possibilities. Correct me if I'm wrong, but I've dived in pretty deep to the scripting but there isn't anyway to do this at the moment. Instead scripts can either recolor sprites or select a new sprite to be displayed. XPZ uses the second style to achieve basically this for wounded/stunned markers on corpses. The ability to blit a sprite on top of the existing sprite would allow this to be done without having to generate a ton of extra sprites for this purpose. There are lots of other concepts it would be useful for, displaying data about an items state on the paper doll, or even maybe a numerical "damage" display when a soldier gets hit.

So I've been digging around a lot in the scripting section of the code to get a sense of what would be necessary to allow this. But this section is pretty wooly so it's somewhat slow going (not an insult, just the nature of the beast). I haven't started a fork yet (don't worry!) but I have dug around enough that I feel I could at least make an attempt at an approach, though I feel it would be somewhat suboptimal.

Using the existing selectSprite scripts as a guide, I could implement a similar method that exposed similar data, but the return value(s) would be used to identify another sprite to blit onto the current sprite. I could imagine making this pretty flexible in terms of returning data that identifies the sprite, sprite library, and possibly X/Y coordinates (probably... maybe). The blit operation would then be handled using these return values after the execution of the script.

The limitation here is it would allow for blit of only a single item. This is probably good enough for most use-cases, but I figure if we're going to do this feature, might as well make it full featured.

Alas while I have several ideas about how a more full-featured blit could be done, I don't currently see how I would implement them... yet. If people don't hate this idea, I'm willing to work on it though.

Any pointers as to a better approach would be appreciated. The ideas I currently have are:
 * pass in a pointer to a "blit instruction" stack or something. The stack could be filled up blit instructions (and maybe other instructions?) that would get executed after the script completes. Upside is I could imagine how to approach this. Downside is it's basically building a script engine within a script engine, which seems extra pointless.
 * Have the mutations happen while the script is live? A blit operator. This was my original idea but that static operators are, obviously, static, and would lack the proper contexts, which means it would need to be provided by the script execution engine. Maybe this is something I can crib from the recolor scripts? I haven't dove into them yet.
 * Pass in the surface? This seems reasonable and the script could mutate it to its hearts content without much risk. The issue, again, is lack of context. A surface object lacks easy access to the other sprites. I suppose the appropriate SurfaceSet could also be passed in, though passing data between the two via the script seems like a dubious idea (if perhaps possible).

In all cases this operation would run as a separate script, probably after the selectSprite scripts have run (in the same context though). Anyways, thoughts welcome.

2

OXCE Suggestions Archive / [Suggestion] Statstring Enhancements

« on: March 14, 2023, 05:33:46 pm »

So I make fairly heavy use of stat strings, a feature I quite like. And for mods that have a lot of soldiertypes (like piratez) the ability to set stat string by solidertype is a welcome addition.

However, it also means having to set a big-long list of statstrings for all the soldier types, which is both tedious and often open to error when setting values for soldier types that are similar but not identical. And in any case, it seems often the information I want to know is how far (that is, what percentage) a stat is from its cap.

So, why not add the capability of setting a statstring on a percentage basis? The design I am contemplating is pretty straightforward. In an existing statstring block, we simply add another (optional) option to the "range" array after the existing min and max scores. Something like...

Code: [Select]

statStrings:
 - string: "x"
   psiStrength: [~, 30, p] # percentage based
 - string: "P"
   psiStrength: [80, ~] # field absent or any other value, normal behavior
Quite compact and backward compatible.

The disadvantage with this format is that it no longer looks quite so "clean," and I guess it's maybe no longer copy-and-paste backward compatible with x-com util, though I don't know to what degree that is still valuable. Alternatively, the tag could be placed at a higher level, but this eliminates the ability to have differing percentage-based and non-percentage-based conditions within the same rule.

While I am in here working on this, it also occurs that some people might find it desirable to set conditions on an absolute basis. That is; currently, stat strings only take a soldier's "base" stats into account. But with armor, commendations, and other bonuses, a soldier's stats can rise or fall above or below that level. Some people might want to apply statstrings based on this augmented level.

This could be accomplished by adding yet another field to the array after the percentage-based marker, which I don't hate as a method, though at this point, it is becoming somewhat bulky. I'm open to other suggestions.

This is a fairly small patch, so I'm already working on it for my use. I'm not asking for anyone else to do so. I'm just trying to get feedback on what might be desirable. And what might be necessary to get this accepted?

One last thing. While I'm at it, one other minor feature I'd like to bundle with this is the ability to customize the statstring divider, which is currently hardcoded to be a "/". Ideally, I would add this as another translation string, but as the "Soldier->getName" function where this logic resides does not derive from state, I'm quite a long way away from having access to the "tr" function. Other similar classes handle this by passing the language along with the call to "getName," but Soldier does not (because soldier names don't need to be translated). I could add that argument to the method, though this would be a fairly far-reaching change for such a minor feature. Alternatively, since "Options" are global, I could put the functionality there since it is not technically a translation anyway. Open to suggestions on this point as well.

Thanks for your attention.

3

XPiratez / "Submod" Items Only Active When in Proper Slots

« on: March 12, 2023, 08:34:17 am »

So I can't rightly call this a submod... yet. For the moment, it needs some minor manual adjustments to the base mod to function.

What this mod does is uses a new script to have various passive items (Like gasmasks and shields) only be active while they are in the proper slot. That is the hand or the head, as appropriate. At the same time, restrictions on item placement have been loosened so these items can be placed in your belt backpack or otherwise when you do not need them. I found this most useful for the shotgun shield, which can fit nicely in the 2x2 belt slot when not in use.

For now, I have restricted functionality in this mod to items whose use location is self-evident and which could be easily removed or put on in the field. Primarily hats and shields. The basic principles present could apply to any item. Included is a YAML file with possible rules for most of the passive items in the game. You can include these at your preference.

This also patches some minor "bugs" such as Ninja Fans having their resistance effect regardless of the location they are in.

To use this "submod" put it in the mod folder, like any other mod. Then go into "Piratez\Ruleset\Yankes_Scripts.rul" and do the following:
  around about line 3123 add the following line

Code: [Select]

- new: ITEM_RESISTANCE_SCRIPTdirectly above where it says "- offset 3"
remove the "-" and correct the spacing so that the "o" in offset is in line with the "n" in new.

  around about line 3785 add the following line

Code: [Select]

- new: ITEM_STUNMORALENERGY_SCRIPTdirectly above where it says "- offset 4"
again remove the "-" and correct the spacing so that the "o" in offset is in line with the "n" in new.

Activate the mod and that's it, enjoy!

4

OXCE Suggestions Y-script / [suggestion] Script Hook when moving item in paperdoll screen

« on: March 12, 2023, 05:51:29 am »

So a limitation apparently in the current library of scripts in use is that passive items (like shields or gas masks) are always "active." Regardless of where they are equipped. To enforce these items behaving logically, items are restricted in what equipment slots they can be placed in. So a gas mask can only be placed in the head slot, and a shield only in the hand slot. This is fine but eliminates the possibility of carrying a shield or a gas mask in one's inventory and equipping them when the situation calls for it. And also for picking up such "passive" items and carrying them off as loot without equipping them.

So I'm going through and enhancing some of the existing scripts with a modification that causes them only to execute when an item is in the proper location. Since the proper data is exposed in the newTurnItem hook, this can all be done with existing scripting tools which is great.

And for most items, the resulting functionality is fairly self-evident. It seems self-explanatory that a shield or a gas mask would only have an effect when worn in the proper location. But for various other items (for example, jewelry that provides a passive buff), it might not be.

For these situations, it would be beneficial to have a scripting hook that gets called after an item is moved to a new location on the paper doll, which can return a message that gets flashed to the user. Via this means feedback on the items state could be provided.

Additionally, this hook could be used to activate items that otherwise, I believe, would not have a chance to get activated (or deactivated) again until the next turn. Meaningful for reaction fire, for example. Currently, it is probably possible to drop a shield but retain its protection until the end of the turn in many mods. (Implementing this would probably mean a lot of code repetition, but I don't see a way around that with the current set of tools available).

It would be great if this would be exposed in all places the paper doll is exposed, the basescape equip screen, the pre-mission equip screen, and obviously, the in-mission equip screen. But probably not if it conflicts with the ability to "activate" equipment as described above.

I'm willing to take a stab at this if it does not seem unwanted, though I admit it would be a stretch given my current knowledge of the code base. But you know, that's how one grows (though I am more than willing to step aside if someone else wants to do it).

5

XPiratez / [submod] Another submod, Catgirl Resurrections.

« on: March 08, 2023, 06:25:10 pm »

Should cat-girls have 9 lives? Sure, why not. This sub-mod makes it possible. The new research subject is called "Invest Neko Fortune" and requires Soldiers: Neko, and Offerings to Purple Bloom.

6

XPiratez / [Submod] Cat Hover Armor

« on: March 07, 2023, 09:02:40 pm »

So I plan on making more of these, but this first one is done. It's a cat version of HOVER armor... sort of. While in development, things took a bit of a turn. I decided to add a jet-pack-looking structure, similar to the Lokk'nar night flyer, to make it obvious that it is flying armor. And that informed other decisions. So while it's still medium-ish armor (~75% of tactical armor), it has no encumbrance gain (though it weighs 0). Instead, it increases energy regeneration and makes all flying movements count as running (75%). You can still run while flying, bringing your move cost down to ~50%. Normal ground movement is more expensive, however (125%).

I might play around with these values some more (as well as the construction recipe) as I see how they play out in the game. But for now, it's ready for you to play with if you want.

7

OXCE Suggestions Archive / [Suggestion] Display missing health/mana in SoldierInfo screen.

« on: March 02, 2023, 01:20:12 pm »

Another small one while you're chewing on the last bigger one: a way to display the health/mana a soldier is missing while recovering in the Soldier Info screen. Currently, this information is tracked, but not presented to the player in any concrete way beyond the return to service countdown. I am envisioning displaying this by having a 3rd segment of the stat bar that proceeded from the right end towards the left, to visualize the missing health.

While admittedly, the utility of this information is low, I think it would be a neat "nice to have" feature. And in addition, the features I would have to build to support this, likely an extension of the bar class to support this 3rd bar could be useful elsewhere, such as the alternate take on painkillers discussed elsewhere that appeared interesting to me.

Open questions with this enhancement would be: Should the number displayed for health/mana reflect this figure? It seems like it should, though you are somewhat inaccurate information. But, OTOH, the numbers already reflect modifications due to armor, and the utility of knowing the "true" health score of a wounded soldier seem somewhat limited.

8

XPiratez / [submod] Aquacuffs

« on: February 28, 2023, 05:47:46 am »

So I have always loved the idea of manacles. Very piratey, and I'm taking a lot of prisoners anyways. However, in practice, they are kind of borderline unusable, requiring both hands and a lot of TUs, meaning it's almost an entire turn to use them. And they are kind of heavy to boot.

However, through the wonders of technology, the gals could reasonably do better, so introducing Aquacuffs^TM.

Basically, these are high-tech zip ties. Identical to Manacles in function, but they weigh only 2, come 3 to a bundle, and require only 45% of your TU to use, one-handed. Strength is identical to manacles, 50 (though honestly, I'm not entirely sure what this means in practice, haven't investigated the script deeply.

They are unlocked for free when you get Aquaplastics. Manufacture requires 1 Aquaplastic and produces 5 bundles at a time. (Aquaplastics being rather precious to start makes this another balancing factor). Also, coming 3 to a bundle is also kind of a stealth nerf, in a way, since you have to stash them after use.

Mod comes with a custom graphic and sound effect. I'm happy enough with the new graphic, but I am admittedly no artist.

I think there is some design space left for even more sophisticated "smart cuffs" that would be stronger and even faster to use, but the entire concept is kind of marginal, so unless there is a lot of desire/interest, I don't think I'll extend it any further.

Also included is another rule file that buffs regular manacles only to require one hand and 65% of your TU, making them not quite as painful to use. Simply delete the file if you don't want these changes.

Fair warning, this doesn't crash, but I haven't tested it extensively yet.

9

OXCE Suggestions DONE / [DONE][Suggestion] Manual Promotions

« on: February 23, 2023, 06:25:51 am »

So a feature I have often wanted is a way to handle promotions manually. I know some people don't mind/appreciate the automatic promotions, but I've never been a fan, and I can dislike how sometimes an inferior soldier ends up promoted simply because they had seniority when a position became available (maybe this is realistic, never the less, I dislike it).

As I see it, implementation would be fairly straightforward. The existing `SaveGame::handlePromotions` function would get split into two functions, one that identifies openings (the current first half of the method) returning a `PromotionInfo` object with the available openings and one that then processes the promotions. When this feature is enabled, the debriefing screen will instead display new openings (if any) after a battle. I think new generic translation strings may be necessary for these openings as I know the rank titles can be overridden on a per-soldierType basis (I haven't investigated this yet, though). Some fallback option is probably possible to not-break existing mods.

To actually perform the promotions, I envision clicking on the rank icon (turning it into an interactive surface), which would open up a screen very similar to the SoldierArmorState window, except it would be populated with possible promotions. Clicking on the rank would then promote the soldier. Additionally, it might be desirable to have a "Promotions" view accessible via the combo-drop-down from the soldier screen in the same way the transformation overview screen is. This has the advantage of being more visible as the fact that you can promote via clicking the rank icon wouldn't be immediately obvious, I think. This implementation would be more work, however, so I do not envision creating this screen in an initial implementation.

Questions I have:

• If I was to implement this, would it be a patch OXCE would be open to accepting? To be clear, I'm motivated to make this modification simply for my own desires, but I'd be more motivated if chances were good it could be accepted more wildly.
• As I laid it out, the promotion screen would display all open positions, allowing (potentially) a rookie to be promoted to commander if desired. This is not typically how it works in the game. So instead, the promotion screen might simply give an option to promote to the next rank, if available. Ironically I think this would be somewhat more work to write, as I can't just crib off the existing windows (though there is probably a "confirmation" type window someplace I can crib-off of). Promotion from rookie to commander would still be possible, it would simply take more clicks.
• Should demotions be possible? A "demote" option could easily be added to the list of possible new ranks. In a "single-step" promotion scenario, the window that pops up could give promotion and demotion options. Alternatively, one might right-click on the rank to demote and left-click on the rank to promote.
• Should the existing promotion pyramid be enforced? That is, should it be impossible to promote a soldier to say sergant until an existing captain vacancy was filled?
• To what extent is it desirable for the above rules to be configurable? Should the ability to demote be an additional configurable option? How about the ability to promote from Rookie to Squadie?

So yeah, mostly concerned about the shape of the UI and configuration options. My inclination is, of course, to do the easiest possible implementation for a 1.0 feature, but I don't want to road-block future decisions with decisions made now (which probably means going for single-step promotion since I can later switch to multi-step promotion, but switching back would probably be disruptive).

Looking further down the road, it occurs to me that making ranks more configurable in general is probably desirable, and it's something I might be motivated to work on later, so I also want to avoid getting in the way of any configuration in that respect. However, it does occur to me that manual promotion might be a desirable feature in such a future, even for people who dislike the concept, if ranks were to become more unified with transformations in general, and so that, for example, a promotion might be a "transformation" that comes with both a benefit and a cost. For example, promoting a soldier to Captain or whatever gives them bonus stats, but requires them to be transferred off base for a week at Officer School, or whatever. I know some mods already do this via the transformation screen, but unifying the two might be desirable and could help make the drop-down not become so cluttered.

10

OXCE Suggestions DONE / [DONE][Suggestion] A way to display statCaps on the soldier info screen

« on: February 21, 2023, 04:58:55 pm »

While playing xpz (and I assume it would be similar for any other long-running mod), I have often desired to see if a soldier has reached the cap of their stat. But this information is not displayed anywhere, and it can be hard to keep track of mentally what a soldier's stat caps are when there are many different soldier types in play.

This enhancement was so mild I thought it would be a good low-hanging fruit to try and do myself, so I did. I have already sent in a pull request with this new "stat cap" feature. When a soldier's stat is at its cap, it will be displayed in the color2 color, which is configurable. A demonstration mod is also included in the pull request.