OXPs - Strategic thinking!

[another_commander]

Just tried it here because I wasn't sure myself and this is what I found: To set a key with Shift, you must set it like this (example with the "F" key for showing fps):

Code: Select all

key_show_fps = ({
            key = "F";
            shift = true;
        });

The key must be set as captial F and shift = true; must be present. Alternatively, you just do it via the in-game interface and you will not have to worry about any of this.

[Reval]

Thanks again. Actually I found, when redefining arrowLeft and arrowRight for Yaw left/right, that I got a mixture of yaw and roll when leaving the station. It appears that Oolite is interpreting both the new definition and the former definition.

[Reval]

Sorry, what I meant to ask there was: is there a way to 'nullify' functions that you don't want to use (like roll) with "" or some other code?

[another_commander]

The issue with yaw and roll is something I do not see when I use the in-game interface. Actually, the in-game interface warns me of conflicts as soon as I try to swap the roll and yaw keys and prompts me to resolve them. If you are editing keyconfig2 manually, then maybe you are unwillingly introducing such conflicts.

As for nullifying keyboard assignments, again using the in-game interface, press 'u' in the keys menu to unset a function.

[Reval]

I actually did redefine the Yaw in game, and I didn't see any warning of conflict in the interface. But perhaps I wasn't paying close enough attention, or wasn't familiar enough with the steps. I'll try it again now that I know more. Thanks.

[Reval]

I'm still having trouble here redefining alphanumeric keys...

I entered "k" for 'select next compass target' in game and immediately got a conflict warning. However, running down the entire list, I don't see "k" already defined anywhere.

Question: what does "overrides" - "yes" mean?

Question: if I redefine alphanumerics in game with the (default) US key map, will those definitions carry down through all the other national keyboards in the keyconfig2.plist? (it is a very long file now we're including all of those!)

[another_commander]

I entered "k" for 'select next compass target' in game and immediately got a conflict warning. However, running down the entire list, I don't see "k" already defined anywhere.

You 've just discovered a bug. "k" is the key to change field of view in real time in-game, but this feature is not compiled into the executable. Still, the key configuration code sees it as present and that's why you get the conflict warning. Will be fixed.

Question: what does "overrides" - "yes" mean?

I think this is just an indicator that you have changed the default key binding for the specific action.

Question: if I redefine alphanumerics in game with the (default) US key map, will those definitions carry down through all the other national keyboards in the keyconfig2.plist? (it is a very long file now we're including all of those!)

No. Those settings will work if and when you set your keyboard to "US" in Windows. If you switch to "ES" you should configure your keys for ES. Best thing to do is decide what keyboard configuration you want to use when playing the game, select it in the keyboard layout option and configure the keyboard for that layout.

[Reval]

Ah, so now I assume it's best to reset everything and go Latin American?

Can you give any idea as to when the "k" bug will get a fix? And how will I know when it has?

[another_commander]

I think yes. The whole point of the new keyboard code is that keys now are recognized in their correct positions on all supported keyboards. You can of course choose to continue with the US configuration if you want, but this would be the same as we've had till now, with some keys on non-US keyboards being problematic (like '\', '`' etc.).

The 'k' bug is already fixed on my PC and should be getting checked in later in the afternoon, Athens time. You will have to keep an eye on the github latest release page (where you already got 1.91 from) and specifically the Oolite Windows Nightly pre-release section at the top. This will be automatically updated within a few minutes after the fix has been checked in.

[Reval]

Great! I'll hang on for that then - well, perhaps I'll sleep a little first

[Switeck]

Something I'd really like to see is at least 1 more hotkey we can define for activating OXP/OXZ equipment.

Like so in the keyconfig.plist file:

key_fastactivate_equipment_a = "0";
key_fastactivate_equipment_b = "\t"; // tab
key_fastactivate_equipment_c = "O"; // new tertiary mode!

[Milo]

Something I'd really like to see is at least 1 more hotkey we can define for activating OXP/OXZ equipment.

Here is a diff from my private build (synced with latest nightly) that adds two additional fast activation keys, defaulting to [ and ] but modifiable like the originals, and changes the function of CTRL + fast activation key from priming the equipment to toggling its mode, so you can operate five different pieces of primable equipment simultaneously (four through the fast activation keys, and one through the normal SHIFT-N/CTRL-SHIFT-N cycle with b and n keys).

https://pastebin.com/9cL1pb3M

[Switeck]

Sadly, I've never had much luck compiling Oolite.

[Cholmondely]

One of my (lot) WIP's include a small fleet attacking the main planet, admiral orders, drop shuttles and bombardment included before the entire fleet is going down on the planet. The entire scenario is tested and is working.

If you like, I can upload the OXP for you so that you can have a look. Warning ! The package includes various other (harmless) scenarios as well, like a hospital ship sending aid to a planet or the behavior of traders too large to dock.

Goodness me! Hero! That sounds absolutely super!! Well done!

I'd love to see it! Will you be calling it "Montana's Monumentally Murderous Modifications"?

Here we go:
https://app.box.com/s/35s7upenqndlm53kfoy2kqp9crqay8z8

Please remember it is a WIP so a bit chaotic and not cleaned up and therefore not useful to publish in the current state. BTW the name is simple Lambda Series

Just wanted to ask how your "pièce de résistance" is coming along...

[Cholmondely]

An example of an idea I've got knocking around that will be absolutely painful to code...

[Briefing:]

Vice Admiral ____ says:

"Showing the flag" can be very expensive even if Thargoids aren't shooting at us.
Consumable supplies and paid personnel alone is expensive enough, but pales compared to the ships.
While it doesn't typically destroy or significantly damage ships to do this, the time spent is time we can't fight Thargoids elsewhere with these same ships.

The biggest problem is getting all the ships to the destination system at the same time.
Multiple ships have to travel together, with the size of the convoys based on the urgency, danger, and distance from the starting system.

To start the route, the lead ship jumps to a nearby system.
The other ships in the convoy then use the wormhole that creates -- instead of burning their own fuel to jump on their own.
Freighters do this all the time with their non-jump-capable escorts.

After all the ships are through the wormhole, they organize in preparation of making their next jump along the route.
The lead ship is swapped out for another ship that has sufficient fuel and can fight unassisted at least briefly while the rest of the convoy follows through its wormhole to join it.
Then that new lead ship jumps to the next system along the route.
The process continues until the convoy's destination is reached.
This way each jump only consumes the witchspace fuel of 1 ship.
Some extra ships are often included to deal with contingencies, but we are spread much too thin to do this regularly.

Large Navy convoys have crossed entire Galaxy Charts in this manner without ever docking at a station or sun-skimming to refuel.
Only observers near the witchpoint buoys of the systems traveled might see their passage.

Crossing the Great Rift in Galaxy Chart 7 to reach the large cut-off region has for a very long time been an open secret used by large trading corporations, the military, ...and smugglers from what I've heard.
1 ship misjumps halfway between 2 systems at the edge of the Great Rift.
Other ships in the convoy are then able to jump from that interstellar point to a system across the Great Rift.
The bugs seem to have caught on that we're doing this regularly, because we sometimes have to fight a sizable Thargoid warship force at these interstellar locations...and ships have been lost or damaged in these fights, though fortunately not entire military convoys so far.
We'd like to be able to quickly send a smaller force that is less likely attract attention of both the bugs and various system factions that seem out to cause chaos while we're not around.
Ideally, just 1 ship...but until now that was deemed too risky even for our fast Asps.

An independent explorer, initially without funds from us, discovered additional paths across the Great Rift.
The best such paths offer savings for our logistics.

The yearly expeditions to "unreachable" systems using multiple Galactic Hyperdrives has a very high cost -- often via a Behemoth due to its cargo capacity and ability to act as a ship carrier. We cannot afford to send a Behemoth alone, so it may have a small fleet with it.
A partial payoff comes from deliveries of Galactic Hyperdrives at far above normal market prices and transportation of stranded people to the next Galaxy Chart region for a fee.
We even buy up some ships for cheap that we later refurbish and resell.

Oresrati in Galaxy Chart 8 is the worst regular Navy expedition destination due to it lacking even a single nearby trading system.
But that has changed, thanks initially to a rumor that a specially reprogrammed Gal. Hyperdrive is no longer needed to reach it.
A Galactic Navy special operation confirmed It is reachable via a misjump route from nearby systems.
Once there a Gal. Hyperdrive is still needed to LEAVE it.

[END BRIEFING]

...Now, the reason why that's going to be painful to code is the forming-up process after each jump.
Ships can get separated, some even destroyed...have to be extras to handle such contingencies as well as "leave no one behind".
It's slightly easier if the ships are in 1 single-array group, so each can be selected with $ship_group[ship_number] instead of having to fiddle with search-for-nearest ship looping and trying to determine if each ship so found is even part of the loose group.

There's also the problem when more than about 5 ships dog-pile a single wormhole they come out on top of each other on the other side, sometimes comically...sometimes explosively.

Switeck - "sometimes explosively" - is this what actually happens?

Also - is this really not included in the Galactic Navy.oxp programming? I presume that it is/was going to be part of the HIMSN programming (eg. the unpublished Stage 2's yearly parade).