Improving LRS - kind of planification - Adding a Knowledge Base system

[Stigmate-Fr]

Hello, Fellow space nerds

(Pew Pew Pew 🚀 ❤️ 🔫 )

I have some suggestions (no code to provide, just concept),
But they require button mechanics that i haven't seen anywhere in the game.

• Either a drop-down menu
• Or cliquable left and right arrow keys (UI), which modify the display of strings or mini 3D view.

Without these, the system seems harder to implement.

Two system described here, but working together

• A "by player ship" knowledge base system (extendable to StarBase)
• A LRS modification that integrate this KB system
  (in echo with Long range scanner is confusing and not helpful enough #261 )

The concept would make it possible to have a semblance of a readable Knowledge Base, without having to use the Demon.
(Note : the Demon's UI, in a “Simulation” version of the "player/computer's knowledge of the world" would surely be top-notch!)

We could consider this suggestion of evolution as a “planning” mode, and would therefore perhaps merit a dedicated view, rather than integration with the LRS directly.
This would make it possible to monitor the ship's perimeter, while another officer/captain/Navigator.. does the research.
But in itself, I think it's better to have this in the LRS, to deepen the Science role.

I hope this will ring some bells for this beautiful SBS that is SNIS 🤟

Concept

Objects have a new property: predictability.

Meaning :
The emplacement of planets, asteroid fields, (maybe even stations and warp-gates), can be considered predictable.
And therefore could be stored in a ship-specific knowledge base.
(In the Ship file? )

This information can perhaps be bought from the stations, for a derisory (planet)
or very high (asteroid fields, money-money) price.
And, more naturally, every time the ship scans a predictable, it is added to the ship's knowledge base.
(With scanned ship support ? automatic, or manually ? Deletable ?)

An alternative LRS view become a way to parse this ship knowledge base.

UI

For understanding, I divide the view into two obvious panels.
Panel Left, is the left part of the LRS, Panel Right, is the right part, with the permanent “Details” frame.

Let's start with Panel Right

A new button at the bottom:
SRS - LRS - KB - Details
(Knowledge Base)

Right panel now has an additional mode called Knowledge Base, which transforms the Details frame into a new model, same size :

• It allows you to select a system (UI arrow, or drop down menu)
• It lets you select an object type (UI arrow, or drop down menu)
• There's a 3D display area underneath, with clickable left and right arrows, for navigating known objects.
  (The ultimate mechanic would also permit to keep information on scanned vessels, but with an “unknown” position if the object is no longer scanned).
• If no object is selected in the LRS view, the detail button returns the details of the selected object in the KB.
• If the KB Sync button is checked in the left panel, the object displayed is targeted on the left panel, or, if Align to Ship is checked, an arrow indicates its direction.
• Details button do what he does usually, and zoom on 3D model and information.

Left panel

Options at bottom

• Align to ship
• Unknown Object: Enables/disables dynamic masking of unknown objects (readability ++)
• KB SYNC (or Plan Mod):
  • Targets in real time the objects selected in the knowledge base, and maybe filter the objects displayed by keeping only the family selected on the KB panel.
    Ex: I only see planets, or stations, etc...
  • My view of the system can be "out of radar range"
    and the maximum range gives me so a full view of the system, with only known object.
    (if possible, can see object of another system, but i presume game design will not permit this ?)
  • We should keep the display of neutral/enemy ships within a certain range of my ship.
  • If I need to switch back to SRS mode, or simply uncheck KB SYnc, my KB view retains its state.

Gameplay :

Planning

• We could envisage, if math possible, that targeting objects in KB mode would be able to indicate a little more route information.
  A jump through Warp Gate + all the warp needed + indicate possible Starbases stops along the way.
  (NO STEPHENMCAMERON - STOP TO HATE ME, RIGHT NOW)
  (Or i open a discussion to ask to integration of web-radio support that cut with Red Alert system and voice-call)

Bounty hunter, cargo, mining, passenger :

This knowledge system could be applied to Starbase missions.
And bounty (but maybe it's already the case with registration query, which I haven't quite figured out).

• The mission creator can, via mission script or live, add the information of the searched vessel to the KB of the player vessel.
  The Bounty Hunter mission gived by Starbase also has this feature.
  “Such a ship type, Such registration code, Last know coordinate etc”.

• Stations also keep a register (their own KB) of past ships, and can provide, for a fee, this information to the player, by radio.
  (Other bridge hunter <3)

Taking any type of mission could add object information, or even the possibility of targeting a waypoint at a distance in this KB view, since it would be decorrelated from the radar “range”.

Et voila
I hope this can bring some inspiration !

Thanks for reading

[smcameron]

There's a lot here and I'm not going to address all of it right now, but I would like to mention something in case you are not aware of it.

... mechanics that i haven't seen anywhere in the game.
Either a drop-down menu ...

I'm not quite sure what screen you're talking about here, NAV, or SCIENCE. If you are talking about SCIENCE, did you know that there already is a drop down menu? You might not, because I elected to hide it when not in use. But if you move your mouse to the upper left part of the screen drop down menus will appear, and you can select various ships, planets, starbases, warp gates, etc. that you have scanned from those menus. Maybe you already knew about that. Demon screen has a similar menu in the upper right part of the screen. Perhaps I should make these menus always visible by default with some option for the hiding behavior.

As for an in game "knowledge base" ... what specifically do you imagine would be in this knowledge base? Right now, the "details" part of science has some small amount of info about planets, ships, etc. A lot of that is fluff, information that is window dressing but is not actually very useful to the player except as ambiance. I suspect you have in mind a vague notion of some information that would actually be useful to the player. Like what, specifically? That kind of stuff is hard to come up with.

Another thing to consider, if you remember the Star Trek TV show, the characters would often consult "the computer" about things, and that was the knowledge base aboard the Enterprise. I have tried to replicate that, in a limited way. For example, on COMMS, you can type "/computer how far is it to sb-00", or, "/computer describe the nearest planet", or you can ask it anything, just precede it by "/computer", although, I admit its grasp of English is quite limited. And if you would prefer to talk to the computer as they did on Star Trek instead of typing that is also possible -- although even more gimmicky and frustrating. But my point is "the computer" is another place to put bits and pieces of knowledge.

web-radio support that cut with Red Alert system and voice-call

Not quite sure what that means. Right now (iirc), the voice chat system (push to talk system) has two modes, F12 just transmits audio to members of your same bridge, and Ctrl-F12 transmits to all stations on all bridges in the snis_server. The voice chat was added during COVID to facilitate over-the-internet play, but I do not know if anyone has really used it. I've never played a game with multiple bridges for real (only testing by myself), and I kind of doubt anyone else has either. It has of course crossed my mind to have an in game radio, or even (like Star Trek) video chat, but a) this is probably beyond my abilities and b) it's a lot of work for a feature nobody would use because almost nobody can gather even one crew to play this silly game, much less two to necessitate such a feature.

Alright, that's enough for me for now.

[smcameron]

One more thing, if you really want to add things to the game to make it more than just a ship that you can fly around in space, I think what is really needed is more Lua mission scripts.

• https://github.com/smcameron/space-nerds-in-space/tree/master/share/snis/luascripts/MISSIONS

Reading through the documentation for the Lua API may give you some sense of what is possible.

[Stigmate-Fr]

Shame on me!

If you are talking about SCIENCE, did you know that there already is a drop down menu?

Yes, I was talking about the Science station.
I've never found those drop-down menus!
It's exactly what we needed to navigate :o
It was hell without it!
(What a great job Dude...! )

Perhaps I should make these menus always visible by default with some option for the hiding behavior.

Yes! Or maybe just a discreet high chevron [ ^ ] pointing to it. That would give players a clue that's not too intrusive.
I'm checking everywhere now,
I've discovered the one in the lobby! No more retyping the iP for every test ❤️

That kind of stuff is hard to come up with.

I'm well aware that it's difficult, and it's obvious that you've already put a lot of work into your game!
I just hope to give an idea, because I like it, but we play it in a particular configuration.
(Father-son duo! Sometimes trio with madame, but rarely).
I'm not coming with a “request” mindset, but a suggestion's one 😄 😉
(Maybe one day I could find time to hack it too)

As for an in game "knowledge base" ... what specifically do you imagine would be in this knowledge base?

I'll need some time to structure my idea and my answer, to avoid it being too wordy.
And because we are pushing more gameplay and hacking to discover what we could have missed.
I'll reply soon.

web-radio support that cuts with Red Alert system and voice-call

Oh sorry, just a joke!
(Inspired by Dansteph's OrbiterSound mod in Martin Schweiger's “Orbiter” simulator)

Joke's Like: It's a difficult function to develop, with a lot of work, for a nice little function that's not useful at all!
French humor perhaps... 😅

[Stigmate-Fr]

I'm going to contextualize my answer to make this idea understandable...

I'm in the process of adapting the game to a 2-player easier version, maybe 1player too.
Because we play mostly in duo.
(With my 9-year-old son, who run the turret and the scanner).
Sometimes my wife helps out, but it's rare.
(yet, everything becomes so much simpler... 😄 )

So I've done a lot of configuration to minimize hardware and maximize transversality between stations.

Example:
my son plays on a laptop with a second remote screen, and a wireless XBOX360 controller for the turret.
The actions of the controller are transferred to the SCIENCE screen,
so even if the scope is on the SCIENCE screen with the mouse, it instantly controls the turret all the same.

I've made other cross-functional configurations for the pilot's station, for example, with the weaponizing configuration of an X52 Pro, where i can manage missile.
(I will transmit a more normal configuration for the joystick file soon)

So we're playing more an X-Wing crew than an Enterprise's one :D

For my part, I manage the other screens, and it's very difficult to manage the Bounty and mission conversations, for example, when the SB spam attack reports.
Knowledge Base can help with that. And more.

As for an in game "knowledge base" ... what specifically do you imagine would be in this knowledge base?

The data I'd see in a knowledge-base probably all exists already.
They are just often difficult to Read/Re-Read, for example because of SB-Spam.

So there is two concept in my idea.

The first use drop-down menu's entries.

Example:

• Bounty
  Exploiting information is hard.
  The SCIENCE officer starts scanning the LRS, looking at all the ships to see if any have a bounty.
  This makes bounty tracking a separate, somewhat repetitive activity.
  Instead, the idea would be:
  Each time COMM requests a bounty list, ship KB is updated ( in a dropdown menu entry) and SCIENCES can easily consult the bounty list, with one entry per ship, and all existing information.
  During a fly, if my science officer is a bit free, he displays the bounty list in his menu.
  He becomes familiar with the names to look for, much more easily, and began to looking at the signatures he has on radar.
  If necessary, he can easily find the price, the name and the SB where to collect the bounty in the entry corresponding to a vessel.

• Mission briefings!
  I think this is the hardest part, when the comm officer isn't present full-time, and even when he is, it's sometimes difficult for him.
  Spam attacks on SBs make some briefings very hard to reread.
  In this “KB” menu, comms belonging to a mission (i.e. those added in LUA by the mission creator) could be historized.
  SCIENCES or COMM could therefore access an entry in this menu, with the history of comms (excluding standard starbase comms).

Of course, information on transport contracts, passengers, etc., could also be available in the KB.

The second concept would be based, for example, on the LRS interface,

but in a “parallel” way, as this would be decorellated from the radar constraint.

The information in the knowledge base could be consulted using 3D visualizations.
So the rest of my suggestions tried to see the LRS interface as a way of planning a journey and finding information more easily.

But I realize that this is mainly because :

• I was considering cross-system missions, which in the end seem more difficult to implement.
  Example: Transporting a passenger to another system.
  I buy (or scan myself) the data from this system.
  I measure the overall warp factor (towards the planet and/or the star-base), Ticket Price, and i get statistics on the average number of ships per faction to know if it's a dangerous system or not, and so on.

• I was thinking that i could generate a more greater system to make planet more distant, and mod Warp stat (but im not sure anymore :D)

• It's also because my son doesn't yet have all the right reflexes (scanning the system with the LRS and mooving the beam, asking for more power on the sensors)
  and so making some data “decorellable” from the radar constraint seemed logical and simplifying.

• I didn't know (and still not sure) that the LRS could scan the whole system.
  (If so, reducing the range of the LRS > making information on planets/SBs/asteroids available for purchase in starbases > and being able to set waypoints on them even if these elements are out of LRS range > would represent the gameplay I was envisioning. These data would be stored in the Knowledge Base.)

Even without the user missions, playing in the dynamic universe could already be “constructive” (if you can save the state and regenerate it as is...).

I know that this game is not created to be a two player/one player game.
But it offer an experience and sensations that we doesn't found in the others SBS...
And with the network configuration, it's easier for me to try to bring some other two-player ship in the game, cause i have some other Nerdy-Dads & Son in my friends.

Here was my thought.
I hope it is understandable...
And sorry for the -v !

[smcameron]

Thanks for the detailed feedback. I will give these things some thought. One thing that comes to mind immediately though, regarding the starbase spam, you can shut that off by going on the demon screen console and typing "set suppress_starbase_complaints=1". I should probably make that the default, those complaining messages were put in about 13 years ago before the game was very far along.

[Stigmate-Fr]

Thanks for this !

[smcameron]

I was thinking that i could generate a more greater system to make planet more distant, and mod Warp stat (but im not sure anymore :D)

If you want to experiment with this, try changing XKNOWN_DIM in snis.h.

diff --git a/snis.h b/snis.h
index be08590f..ad23ab67 100644
--- a/snis.h
+++ b/snis.h
@@ -44,7 +44,7 @@
 #define SNIS_PROTOCOL_VERSION "SNIS062"
 #define COMMON_MTWIST_SEED 97872
 /* dimensions of the "known" universe */
-#define XKNOWN_DIM 600000.0
+#define XKNOWN_DIM 6000000.0
 #define YKNOWN_DIM (XKNOWN_DIM * 0.2) /* i guess... */
 #define ZKNOWN_DIM (XKNOWN_DIM)  /* square universe */

But, there are other values and things that would need to change along with this. For example, the renderer ceases to draw things beyond a certain distance, so far away things become not just hard to see, but invisible. The range of the scanners will be too short. etc. etc. Things are "tuned" at the moment to the current value of XKNOWN_DIM (600000), not to say tuned ideally, but tuned. I don't actually know what all the other things are that would need to change if you change XKNOWN_DIM to keep things sane. Furthermore, as things move farther from (0, 0, 0), floating point error increases. You will probably first notice this as jitteriness with the weapons turret. The next to last paragraph in the file called TODO has some links to some ideas of how to mitigate this floating point problem, but writing that paragraph is as far as I have gotten with that. I have learned about this, forgotten about it, and learned it again at least once: #251

I was considering cross-system missions, which in the end seem more difficult to implement.
Example: Transporting a passenger to another system.

You should realize that in its original conception circa 2012-2015, the game consisted only of a single snis_server and a number of snis_clients. That is to say, a single solar system with no warp gates. The warp gate idea was added on after the fact, and in a very rudimentary way. The only data that transfers from one star system to another is the data about the player's ship. What occurs in one star system is otherwise 100% unknown to any other star system. There is no designed mechanism to transfer passengers or any other thing from one system to another, except for player ships. I don't know what will happen if you try to transport a passenger through a warp gate. I should try it, as it might expose a bug. I suspect the passenger locations are "object ids", which are not portable between snis_server instances.

Note also that mission scripts are started within the solarsystem they occur in (most of them re-build the solarsystem from scratch when they start), and are executed by snis_server. Currently the only way to make a multi-solarsystem mission is to basically divide them into separate independent "episodes", as there is no communication between snis_server instances at all, except indirectly via snis_multiverse, and that is only for login information and player ship data.

I didn't know (and still not sure) that the LRS could scan the whole system.
(If so, reducing the range of the LRS > making information on planets/SBs/asteroids available for purchase in starbases > and being able to set waypoints on them even if these elements are out of LRS range > would represent the gameplay I was envisioning. These data would be stored in the Knowledge Base.)

I think the range is about 1/3 the length of the solar system, that is the radius of the science scanner, so covers about 2/3. ships and smaller things are not scannable unless reasonably close (I forget exactly what that means), but planets and starbases are scannable at any distance up to the 1/3 * XKNOWN_DIM limit. One thing about artificially limiting the range of the scanner ... it is sort of annoying to players not to be able to at least detect if not scan things which can be plainly seen visually, esp. planets, so there is potentially some tension there between what's right for game play vs. what "makes sense."

You might be interested to know that this bug exists: #261

[smcameron]

Yes, I was talking about the Science station.
I've never found those drop-down menus!

To help discoverability of these menus, now they appear briefly when you switch to SCIENCE or DEMON screens before hiding themselves.

328e3b3 Make pull down menus appear briefly when switched to new screen
1c0017b Make pull down menus appear briefly when cycling screens

[Stigmate-Fr]

To help discoverability of these menus, now they appear briefly when you switch to SCIENCE or DEMON screens before hiding themselves.

Good accessibility trick for newcomers ! Will update to night

If you want to experiment with this, try changing XKNOWN_DIM in snis.h.

It seems far too touchy for me at the moment.
I've just starded to learn/practice C, and i try to add SDL cooking in the pot as soon as possible.

I don't know what will happen if you try to transport a passenger through a warp gate. I should try it, as it might expose a bug. I suspect the passenger locations are "object ids"
[...]
The only data that transfers from one star system to another is the data about the player's ship.

Coming from outside programming, I'm used to storing information in flat files, and don't hesitate to call them up when needed.
(Like you do for the lobby, with the “last states” save and recall).
But I can imagine that in programming it's not the best solution.

I was thinking that the ship could have a series of files like :

• Passenger
• Manifest
• Knowledge Base

With vulgar csv data.

• Passenger :
  name;origin;destination;price

These elements could be transmitted between universes, or even missions.
(It's just a thought, i'm working to grasp your code these days, and i'm seeing how big is the works behind every idea 😄 )

[smcameron]

Coming from outside programming, I'm used to storing information in flat files, ... I was thinking that the ship could have a series of files like : ... These elements could be transmitted between universes, or even missions.

The problem with this idea is that although it is not the default setup, it is possible that the lobby process, every instance of snis_server, and every instance of snis_client can in theory be running on separate computers, and communicate only via network, so they cannot rely on a shared filesystem.

[smcameron]

Example: Transporting a passenger to another system.

I don't know what will happen if you try to transport a passenger through a warp gate. I should try it,

I just tried it. The passenger disappears. Bug #384

[Stigmate-Fr]

it is not the default setup
[...]
every instance of snis_server, and every instance of snis_client can in theory be running on separate computers, and communicate only via network, so they cannot rely on a shared filesystem.

Yeah... Indeed
The solution would be to build a robust data synchronization module, with a robust serialization - deserialization mechanism, so that the game itself becomes the sharing agent, and centralize the ship's data on the servers, and then, 5 years later, when it works perfectly, make a big disclaimer on the home page “Not Wifi compatible at all”
Haha 😄

But I think there's an important question behind this (which you may have already answered) 🤔
As you've built several star-systems, and an RTS mod, have you thought about some persistence mechanism behind ?

I like some ideas in IDEAS.txt and i have some to suggest, that i maturing on my side while i grasp your code to see what can be done or not, and how.
The KB idea, would be a base system that will permit to extend a lot of these idea i think. But it require a persistence system, and as you pointed out the multiple instance state of the game, an heavy network job and optimization too...

Seems more complicated now 😄

[smcameron]

The solution would be to build a robust data synchronization module, with a robust serialization - deserialization mechanism,

That is what snis_multiverse is meant to be. You can look at snis_bridge_update_packet.[ch] to see what currently gets saved.

Too much persistence can potentially be a problem for me. 1. Right now, players are not super attached to their ships. If, for example, I change something about the way that per-ship data is stored, nobody is too upset if it means their good old ship gets blown away, and they have to create a new one. If there's a lot of persistence, and people accumulate hard won attributes to their ship, they might be upset if that gets blown away by some update and they have to start over. 2. It is very hard to get a crew together for the majority of people. That means games tend to be short transient, ephemeral experiences, with people coming late and leaving early throughout. Who "owns" the ship? The way a ship is identified is by name/password, but the entire crew shares a single name/password tuple. The answer is: whoever runs the snis_multiverse server, and when that person leaves with their laptop they take the ship with them, and everybody else loses access to that particular ship. So the ship cannot be valuable to players over the long term, or there will be trouble and unhappy people.

[vpelss]

Just some thoughts.

I think you have two demographics.

Your current one:
Serious space bridge sims crews willing to take time and effort to gather to play longer missions.

But as you know, it is hard to gather and retain these crews as time is expensive and effort, is well, effort.

The second "potential" demographic is smaller home bound crews OR crews over the internet.
They are likely to play with 2 - 3 people repeatedly and play for shorter time spans.
They are likely to want to retain some of their gained loot, and other things so they can dive back in and continue on.
They are not looking for one or two long experiences but instead a long experience over short bursts of time.
Although you probably don't have the second demographic right now, I believe they are in greater abundance.

I hear what you are saying that you don't want people getting attached to their ships, then fighting over ownership, but if they do, they can copy the hashed ship file and (share) take it with them if they want to find another crew. OK, now you have two or more diverging ships.
But surely we are all adults (maybe) and can work that out.

This is probably a heretical statement, but have you considered having an option for lone wolves (one or two crew ships) to fly in your universes? I am not sure what that would even look like, but that sounds cool.
Empty Epsilon tries to do this with a special station with more controls. Does it do it well? Yes and no. It could be like a single player option. Yes, I said heretical.

[Stigmate-Fr]

That is what snis_multiverse is meant to be. You can look at snis_bridge_update_packet.[ch]

Already Done ! Im notified and consult your issue atm, full of teaching for me !

Too much persistence can potentially be a problem for me. 1. - 2

That's two very good point indeed !!

I am a kind of a "Rogue-like-game-are-the bests" guy... And i forgot that's not the case of everybody.
Regarding the point

players are not super attached to their ships

It is in fact something mandatory regarding the continuous development of SNIS !

On the other hand, not being afraid of "death and loss" prevents a certain level of immersion.

But perhaps persistence isn't necessary to increase this level of immersion.
My first idea, what I missed most when I started SNIS, was a semblance, however slight, of a cockpit, on the main view.
I'm nurturing the idea of being able to make one, that's my first objectiv.

In view of our discussion, if you ever want to go further into the persistency point, maybe you should see the game through a “Captain” profile system, and his fleet.
The question of “who owns the ship” no longer arises, it's decided by the players.
There are too captain's stats (how many ships exist, how many have been destroyed, and maybe other things), and as the game is open-source, it's possible to create the system to backup and easily give a ship to your comrades as they leave...

This makes the game cheatable, but I don't think it's a real problem... (As long as it can't be exploited for anti-game in multi-bridge games).

Anyway, ideas, ideas... Im really to -v

EDIT :

This is probably a heretical statement, but have you considered having an option for lone wolves (one or two crew ships) to fly in your universes? I am not sure what that would even look like, but that sounds cool.

Although you probably don't have the second demographic right now, I believe they are in greater abundance.

There is some little tweak to do in the configuration ! Currently, we play the game @2, and the only missing thing for us right now is the ability to cycle-select trough short target, for complicated situation where turret and nav is occupied.
But it's playable in low crew, and i found the gameplay more interesting than Empty-Epsilon 😄

[smcameron]

My first idea, what I missed most when I started SNIS, was a semblance, however slight, of a cockpit, on the main view

You might be interested in this project: https://github.com/smcameron/snis-consoles though it is a work in progress, and progress is slow. Hardware is not my strong suit. The "notes" page goes into some detail: https://spacenerdsinspace.com/snis-consoles/notes.html

But maybe you weren't thinking of that sort of cockpit (i.e. physical console with buttons and lights and so on.)

The idea of the main screen is to mimic the big screen on the bridge of the Enterprise, like in this video at the indicated timestamp:
https://youtu.be/AusAGjwlql8?t=126 That's why it has a blue rectangle around it (which, btw if you don't like that blue rectangle, you can turn it off via "set blue_rectangle=0" on the demon console.) So ideally, you build out a room in your house to look like the bridge of the Enterprise, and that's your "cockpit". Well, this is beyond my and most people's reach.

This makes the game cheatable.

Eh, it's open source, if people want to cheat themselves, they may. We operate on the honor system aboard this ship.

[Stigmate-Fr]

The idea of the main screen is to mimic the big screen on the bridge of the Enterprise
Dam' ! I haven't the ref ! Now i understand ! 😄

But maybe you weren't thinking of that sort of cockpit

Yeah, indeed it was not that kind of cockpit !
I was thinking to have a third view switch on the Main, that add a kind of cockpit view. But something very light.
I will try to explain that... 🤔

We'd just see the structures connecting the screens.
Like the Enterprise screen, but trying to mimic a real cockpit view.
I really liked this in the Rogue System alpha :
https://youtu.be/sVXUPBDGxRM?si=o6nR-Mk5fPdTAm5z&t=9

Of course, the idea is simpler.
Basically, just add the structural bars linking the screens together, and giving the impression of looking at a kind of reinforced “bay window”, cut out with the central screen, and a piece up, down, left, right...
And I was thinking of creating "switched-off, on, off" behavior for several parts, to give the understanding that these are screens.
(This way it wont be too weird to zoom all screen at once, this become understandable)
And if I could do that, the aim would be to have some screen shut down with dammage, in combat.
Where you could lose some or all of these screens... (I am sure that just a beautiful series of JPEG can do the job, at start 😅 )

Eh, it's open source, if people want to cheat themselves, they may. We operate on the honor system aboard this ship.

❤️

[smcameron]

Well, if you happen to have 3 monitors, you can run 3 clients, and connect them all together to make a widescreen view: https://www.youtube.com/watch?v=xqjor36kdsM You can do the same with weapons as well.https://www.youtube.com/watch?v=NEFGWxXMHJM

…

-- steve

On Tue, Mar 11, 2025 at 5:22 PM Stigmate-Fr ***@***.***> wrote: The idea of the main screen is to mimic the big screen on the bridge of the Enterprise Dam' ! I haven't the ref ! Now i understand ! 😄 But maybe you weren't thinking of that sort of cockpit Yeah, indeed it was not that kind of cockpit ! I was thinking to have a third view switch on the Main, that add a kind of cockpit view. But something very light. I will try to explain that... 🤔 We'd just see the structures connecting the screens. Like the Enterprise screen, but trying to mimic a real cockpit view. I really liked this in the Rogue System alpha : https://youtu.be/sVXUPBDGxRM?si=o6nR-Mk5fPdTAm5z&t=9 Of course, the idea is simpler. Basically, just add the structural bars linking the screens together, and giving the impression of looking at a kind of reinforced “bay window”, cut out with the central screen, and a piece up, down, left, right... And I was thinking of creating "switched-off, on, off" behavior for several parts, to give the understanding that these are screens. (This way it wont be too weird to zoom all screen at once, this become understandable) And if I could do that, the aim would be to have some screen shut down with dammage, in combat. Where you could lose some or all of these screens... (I am sure that just a beautiful series of JPEG can do the job, at start 😅 ) Eh, it's open source, if people want to cheat themselves, they may. We operate on the honor system aboard this ship. ❤️ — Reply to this email directly, view it on GitHub <#376 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAF22GNASXGOQDKCBW5ZJL2T5HZVAVCNFSM6AAAAABXS6RBNOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBWG4YTANQ> . You are receiving this because you commented.Message ID: <smcameron/space-nerds-in-space/repo-discussions/376/comments/12467106@ github.com>

[smcameron]

Ok... I cooked this up real quick...

Kind of going for a millenium falcon vibe.

Behind the scenes, how it's done...

[smcameron]

e620130 small cockpit fixes
f98ff43 Fillenium Malcon cockpit thingy.

You'll probably have to update assets to pick up the stl file for the cockpit. Or type "make share/snis/models/mf-cockpit.stl" and let OpenSCAD build it, then copy it to ~/.local/share/space-nerds-in-space/share/snis/models.

It will probably look weird whenever you dock with a starbase.

Activate by typing "set mf_cockpit=1" on the demon console.

[Stigmate-Fr]

Thanks !! I will it a try tonight !!

[Stigmate-Fr]

And with C no i am on my way to learn Openscad language ! 😄
Thanks Captain !!

[smcameron]

OpenSCAD is a lot of fun. Great for making models for 3D printing too (that is I think the main use case for OpenSCAD.)

[smcameron]

Regarding persistence, this commit,

ae11932 Allow cargo to transit warp gates

should allow cargo to transit warp gates, and persist between sessions. There are some limitations, there is the notion of transport contracts, which attach a source and destination to the cargo. This source and destination are lost in the warp gate transition, or session halt/resume, but other attributes should be preserved. I plan on doing something similar for passengers tomorrow.

[smcameron]

the only missing thing for us right now is the ability to cycle-select trough short target, for complicated situation where turret and nav is occupied.

It's not quite clear to me what you're imagining here. Perhaps you could elaborate?

[Stigmate-Fr]

Yes, sorry. When I don't have Deepl to hand, people don't understand much of what I say! 😄

We had already vaguely talked about it:

It's the idea of being able to cycle the “SELECT” status of the SCIENCE station, between ships in combat range, with a mapable button.
When you're playing with just one other person (a WEAP-SCI player, and a NAV-“the_rest” player)
it's difficult for the gunner to drop his station and switch back to SCIENCE to click on the next target, in a multiple-target context.

The idea was to follow the science_button_realease() trail, and try to create a “low range target cycling” function that could be mapped to a controller or keyboard.

I said I'd look into it, that it would be a little challenge for me!
So far, I haven't really had the time atm!

[smcameron]

9bc76c6 Allow cycling through science targets via joystick
906fbe9 Allow cycling through science targets
05c8bf1 Add auto-sweep beam feature to science

• Now on SCIENCE, there is an "auto sweep" checkbox which will make the radar spin around on its own.
• Now you can press 'n' and 'p' on SCIENCE to advance to the next or previous in range science target. What exactly "next" and "previous" mean can be a bit non obvious in 3D space. I chose to sort the targets by bearing, and go in that order. Other possibilities (not implemented) left to right, by distance. I think anything you choose, doesn't matter, will be a bit non-obvious and arbitrary looking, so by bearing is as good as anything else.
• Now you can use the "next" and "previous" functions by joystick, the keywords to use in the joystick config file are "sci-next-target", and "sci-prev-target". I didn't actually test this part out, but it is a simple enough change that I am fairly confident it should work (famous last words.)

[Stigmate-Fr]

I didn't actually test this part out, but it is a simple enough change that I am fairly confident it should work (famous last words.)

IT WORKS !!! 🥳

I think anything you choose, doesn't matter, will be a bit non-obvious and arbitrary looking, so by bearing is as good as anything else.

I had to test it alone, as my gunner isn't allowed to Space-pew-pew-pew when there's school the next day.
From NAV point of view, using the bearing is very instinctive, and, i think, the best way.
For the science officer, it must be too !

I think distance could have been a good choice in the case where you have a long-range setting in SCIENCE, with lots of ships displayed, and you quickly find yourself in combat.
So perhaps distance could be a “slight” facilitating factor.

But I think that given the ease of pressing these buttons several times, and the existence of visual feedback of the SCIENCE selection on all stations, bearing is still best in most cases!

We'll be testing and reporting back very soon ! 😉

A big big thank !!
Two player experience become very smooth with all your last changes !!