A way to add tracks?

[niston]

This is the texture for the symbols tube I currently use:

 

NixieTubeSymbolsBase_d.dds

[South8028]

25 minutes ago, niston said:

Ah, yes. I agree. It's a 70s style display on an 80s tuner.

Well, the "nixies" in my display are in fact just a texture. The individual numbers are UV animated.
For the numbers tube, it's a vanilla texture: Textures\Effects\NixieTubeNumbers02Base_d.DDS

If you can create a new texture for it in 7segment LED display style?

You can base layout on vanilla texture. New texture must cover dark (nothing displayed) and numbers 0 ... 9.

In addition to numbers, there is another texture for symbols. It must have dark, dot and dash.
Dot must be weirdly and specifically placed, as depicted above.

Alternatively, you could create an entirely new 7segment single digit NIF with at least 13 static states, using all in one texture:
dark, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, ., -  The nixie script will work with it and will spawn these 7 segment LED digits instead.

We can also rescale the digits to be larger or smaller as desired, without much issue. The NiNodes to which they attach to need to be adjusted as they determine the spacing between the individual digits, but that's about it.

I'll finish the tuner, textures, animation (I think it won't take much time). I want to see what he looks like in the game. Then I'll work on this display. If you have the desire and opportunity to animate, I can create a real exhibition. Not textures, but digital meshes. Segments of cryptographic architecture with sequences capable of representing numbers and letters. But since the management method is not clear to me, I cannot accurately estimate the amount of work. Therefore, I don’t know whether this method makes sense or not.

[niston]

Yes. The model looks really cool, finish it up by all means.

Not sure what you mean to say by management method.

It's always been clear to me that the tuner is intended to display the actual frequency it is tuned to. Hence why I mentioned early on the crucial difference about radio frequency precision in real world vs in-game world, so you could consider this when modelling - I even specifically asked you to keep it in mind. That we need moar digits for frequency and that the space the frequency bargraph occupies would best be used for it. Best plans in the universe will fail if communications break down along the way.

I initially brought up the frequency display cause I think its a very nice touch -wouldn't you expect it from a tuner- and because I already have the necessary scripting to back it up in place and know exactly how to make this display work as I've already implemented it in another context. Also I wouldn't know of any other radio mod that has anything like it, so it'd be quite a distinctive feature. You agreed on the display. If you are not happy with the 70s nixie style, it can be made to look like the original device's 7 segment display (as a suggestion) and certainly resizing it is not that big of a deal either.  The fact remains that, in order to be useful, the frequency display requires the given number of digits, due to the admittedly crazy precision required by the game.

If you disagree with the plan of having the tuner show the actual frequency it is tuned to, then let me know. We can drop it if you're unhappy with it.

But I think we have been very successful so far on the User Interface of our stereo system project. You made a gorgeous looking model of a vintage amplifier down to individual parts, and I've brought the these parts to life in game. Exactly as we wanted to. Player can push and click and turn and twist the individual controls on it and it even has (very mild) blinkenlights. It's already way more detailed than any other radio mod for the game, and we only just started out with the amp! And now, we will simply do the same thing for the Tuner and we will be successful just as well. Then we do the reel 2 reel and then a turntable for those beautiful records and finally a holotape deck.

I am working on backend scripting side of things, too - The stuff that makes the actual music. I've tested placing radio emitters on speakers, tested boosting radio volume, tested true stereo vs 3d audio and work on the NetLink protocol for it all has begun. I want to get tuner->amp->speakers working first, because radio is easier to implement than files/descriptor based playback. I'm sure Chuck will be able to contribute on this side. 

Once we have tuner, amp and a pair of speakers ready and playing music, we do whichever one you want to do next.

It will be a very nice stereo system. Much nicer than any other there is.

 

[niston]

@ChuckYufarley Quick primer on the system architecture:

• Sound comes from normally invisible "emitter" objects.
• There are multiple types of emitter objects: One for radio stations and another one for sound descriptors.
• An emitter object can be spawned and attached to a node on a speaker. It is deleted when no longer used.
• The rest of the stereo system is essentially an elaborately styled remote control for the emitters that are spawned on the speakers
• A SOURCE device (tuner, tape, phono,...) controls what is being played (for example, radio emitter, frequency=98.000000, boost=true). For descriptor emitters, playback position is to be controlled by the SOURCE as well.
• This information is passed from the SOURCE to a connected CONTROL device (amp).
• The CONTROL device determines which SOURCE is being played and how loud and where. It adds this info to the information from the selected source.
  Example: radio emitter, frequency=98.000000, boost=true, volumeL=1.0, volumeR=1.0, zone=A
• The information is being passed from CONTROL device to connected SINK devices (speakers).
• The SINK receives the information, spawns the required emitter and configures it accordingly.
  Example: spawn radio type emitter with boost, configure it for 98.000000 and set volume to 1.0. Full blast!
• A SINK can be configured for either 3d audio left, 3d audio right, stereo left or stereo right. It will choose an appropriate sound output model for it's emitters and process commanded volume settings according to the configured mode.
• Changes on SOURCE or CONTROL devices can update the SINK. For example, volume change on the amp.
• Information is being passed between components over the workshop power grid, using NetLink.
• Network connections can be established with wires, through wireless power or through snapping.
• Due to the nature of the network, components can be "physically" grouped together in the game world, put in a single rack, in multiple connected racks, or located all over the settlement.
• Components can be logically grouped into a "System" on the network, using a common System Name. Example: "My System". User may change the system name. Different systems do not communicate with each other.
• Each component can have a name to easily identify it within a system (Example: "IC150 Control Amplifier"). User may change the component name.
• Connections between components in a System can be setup. SOURCE devices connect with selector inputs on a CONTROL device. SINK devices connect with speaker zone outputs on a CONTROL device.
  Example: Connect SOURCE "FM1" to "Tuner" input of my amp. Connect SINK "MySpeaker [L]" to zone A output on my amp.
• The prototype system always and only uses speaker zone A.
• Because the speakers ultimately control sound reproduction, we can assign different sound output models for different kind of speakers. For example a HiFi speaker can be made to sound very different from a PA speaker used in the subway.

[South8028]

7 minutes ago, niston said:

@ChuckYufarley A short primer on the system architecture:

• Sound comes from "emitter" objects
• There are multiple types of emitter objects: One for radio stations and another one for sound descriptors
• An emitter object can be spawned and attached to a node on a speaker. It is deleted when no longer used.
• The rest of the stereo system is essentially an elaborately styled remote control for the emitters that are spawned on the speakers
• A SOURCE device (tuner, tape, phono,...) controls what is being played (for example, radio emitter, frequency=98.000000, boost=true).
• This information is passed to a connected CONTROL device (amp).
• The amp controls how loud it is being played and where and adds this to the source information.
  Example: radio emitter, frequency=98.000000, boost=true, volumeL=1.0, volumeR=1.0, zone=A)
• The information is being passed to connected SINK devices (speakers).
• The SINK receives the information, spawns the required emitter and configures it accordingly.
  Example: spawn radio type emitter with boost, configure it for 98.000000 and set volume to 1.0.
• Changes on SOURCE or CONTROL devices can update the SINK. For example, volume change on the amp.
• Information is being passed between components over the workshop power grid, using NetLink.
• Components can be grouped together on the network through a common System Name (a string).
• Connections between components in a System can be setup, to associate them with selector inputs or speaker zones
• The prototype system always uses speaker zone A

Finished all the textures. I tried to make it as close to the style of the amp as possible. They are manufactured in one standard factor. In the main model we will turn the numbers on the buttons into splines. It's cooler... And easier to animate. Tomorrow I'll animate this model. All LED screens can be animated. All screens are uv-shifted with physical LED meshes. I wonder what it will look like in the game. Most likely very cool. The final design will become clear immediately. How to change everything to fit your display with numbers.

[South8028]

Sadly. It is necessary to make separate textures for the animation of indicators. 3ds 2013 does not pull out uv animation of several d, n, s, g 4k textures. I don’t know what exactly doesn’t work. Perc, or video card. I have 11k video memory, and 32 physical cores and the fps drops to 0. Probably just a crappy 3ds. It works poorly with uv animation, continuously copies all textures in temp and drops fps.

[worm82075]

13 hours ago, niston said:

It will be a very nice stereo system. Much nicer than any other there is.

Starfield displays wish they were this functionally detailed.

[South8028]

In general, not very good. Really bad. We need to come up with something for the brightness of the indicators. I don’t know how digital panels will turn out; LED panels, as you can see, cannot be called bright. Perhaps for the next model fm1 we need to come up with an effect in the form of a halo bsEffectFx with a green glow, moving relative to the movement of the glowMap.

https://disk.yandex.ru/d/DGwpZaO3pVBmyA

Edited May 27 by South8028

[niston]

The models looks really good. I like it.

Re indicators:

Inspect vanilla mesh Meshes\SetDressing\ComputerConsoleKit\Panels\ConsolePanA13On.nif it's a blinkenlights panel.
The illuminated lights in that Panel use separate TriShapes (ConsolePanA13On:7, ConsolePanA13On:8) with a BSEffectShaderProperty instead of the usual BSLightingShaderProperty and Glowmap. I've got a bunch of panel lamp NIFs that IceStorm cut off the vanilla Switchbox for me long ago and they use the same technique for illuminating. Find one of them attached to this message, for further reference.

Reason I'm pointing it out: The emissive multiple of the BSLightingShaderProperty can be raised above 1.0 and it's TriShape will then glow really bright in game. Upping the multiple further, the lights will even bloom.

Edit: Various versions of attached lamp with slight "overdrive" of emissive multiple can be seen in action on this picture.

 

SmallSignalLamp-Red.nif

[South8028]

23 minutes ago, niston said:

The models looks really good. I like it.

Re indicators:

Inspect vanilla mesh Meshes\SetDressing\ComputerConsoleKit\Panels\ConsolePanA13On.nif it's a blinkenlights panel.
The illuminated lights in that Panel use separate TriShapes (ConsolePanA13On:7, ConsolePanA13On:8) with a BSEffectShaderProperty instead of the usual BSLightingShaderProperty and Glowmap. I've got a bunch of panel lamp NIFs that IceStorm cut off the vanilla Switchbox for me long ago and they use the same technique for illuminating. Find one of them attached to this message, for further reference.

Reason I'm pointing it out: The emissive multiple of the BSLightingShaderProperty can be raised above 1.0 and it's TriShape will then glow really bright in game. Upping the multiple further, the lights will even bloom.

Edit: Green version of attached lamp with slight "overdrive" of emissive multiple can be seen in action on this picture.

 

SmallSignalLamp-Red.nif 6.78 kB · 0 downloads

Yes, I can use bsEffdctFx directly for LEDs. On the same principle as the beam. You can really set any brightness. The problem then is the glass. You will have to make bsLightingFx glass on a separate dxt5 texture with transform_changed. The glass through the glass will periodically disappear at angles other than 90 degrees. In general, I'm not worried. I'll think of something. I can make an additional mesh directly above the glass and animate it in sync with the LED panel. Here's how it's done in vanilla. There are many places where light has additional effects with meshes with bsEffectFx.

Simply, in 3ds uv animation of bgs materials is absolutely idiotic. For some reason, 3ds duplicates all uv displacement operations, continuously copying each frame of uv animation to the Temp folder. I don't know how to turn off this idiocy. No one knows. Because of this, cinematics are hundreds of times easier to animate than textures. Moving the light physically is, figuratively speaking, 200 fps. Moving the light with a texture is 10fps.

Edited May 28 by South8028