Jump to content

A way to add tracks?


Recommended Posts

Posted (edited)
51 minutes ago, niston said:

https://www.righto.com/2022/01/ibm360model50.html

Click on "link to simulator", hit the "Run" button and watch them blinkenlights 😄 There's a convenient "Step" function, so you can animate it frame by frame, if you want to.

Super. The position of the toggle switches remains. But you can probably find it in the photo, + a video of work at 360/50, unfortunately there is just chatter without turning on the mainframe. I would like to do havok, but I don’t yet know what the operator of such a system should do. If the npc just flips switches here and there and twists the settings, it will be funny.

Yes, for registers and buttons I have 48 frames of 4K animation. In each frame you can assign a general glowmap setting for buttons and indicators. Buttons, toggle switches, and adjustment knobs are movable and have real movement.

 

Edited by South8028
Link to comment
Share on other sites

Finally:

Spoiler
[07/13/2024 - 02:56:54AM] [NetLink:SOUL:Protocol < (FF068A73)>]: DEBUG - Sending SOUL Packet ([Magic = "SOUL", Version = 1, System = "DefaultSystem", PacketType = 106, Payload = [sourceName = "Wattz FM1", SourceType = 1, sourceData = [frequency = 98.000000, Boost = True, StationName = "Diamond City Radio"]]]) for System (DefaultSystem) to Link Layer...
[07/13/2024 - 02:56:54AM] [NetLink:LinkLayer < (FF068A73)>]: DEBUG - L1TX: NetLink Frame broadcasted to (50) stations.
[07/13/2024 - 02:56:54AM] [NISTRONSoundSystem:Components:SOULSourceRadio < (FF068A73)>]: DEBUG - Source engaged.
[07/13/2024 - 02:56:54AM] [NetLink:SOUL:Protocol < (FF068A6C)>]: DEBUG - OnLinkReceive event (srcLinkLayer=[NetLink:LinkLayer < (FF068A6C)>], inFrame=[Version = 1, destination = None, Source = [NetLink:LinkLayer < (FF068A73)>], LNet = 0, frameType = 8028, Payload = [Magic = "SOUL", Version = 1, System = "DefaultSystem", PacketType = 106, Payload = [sourceName = "Wattz FM1", SourceType = 1, sourceData = [frequency = 98.000000, Boost = True, StationName = "Diamond City Radio"]]]]).
[07/13/2024 - 02:56:54AM] [NetLink:SOUL:Protocol < (FF068A6C)>]: DEBUG - RX filters passed.
[07/13/2024 - 02:56:54AM] [NetLink:SOUL:Protocol < (FF068A6C)>]: DEBUG - Powered and started.
[07/13/2024 - 02:56:54AM] [NetLink:SOUL:Protocol < (FF068A6C)>]: DEBUG - Received SOUL type Frame from Link Layer.
[07/13/2024 - 02:56:54AM] [NetLink:SOUL:Protocol < (FF068A6C)>]: DEBUG - OnSourceUpdate event raised.
[07/13/2024 - 02:56:54AM] [NISTRONSoundSystem:components:SOULDirector < (FF068A6C)>]: OnSourceUpdate event received.
[07/13/2024 - 02:56:54AM] [NISTRONSoundSystem:components:SOULDirector < (FF068A6C)>]: DEBUG - SourceUpdate ([sourceName = "Wattz FM1", SourceType = 1, sourceData = [frequency = 98.000000, Boost = True, StationName = "Diamond City Radio"]]).
[07/13/2024 - 02:56:54AM] [NetLink:SOUL:Protocol < (FF068A6C)>]: DEBUG - Sending SOUL Packet ([Magic = "SOUL", Version = 1, System = "DefaultSystem", PacketType = 301, Payload = [ZoneName = "A", ListeningSource = None, VolumeL = 0.000000, VolumeR = 0.000000]]) for System (DefaultSystem) to Link Layer...
[07/13/2024 - 02:56:54AM] [NetLink:LinkLayer < (FF068A6C)>]: DEBUG - L1TX: NetLink Frame broadcasted to (50) stations.

Source (Tuner) is FF068A73, broadcasting Source Update packet (type 106) to network.
Director (Preamp) is FF068A6C, receiving Source Update and broadcasting Zone Update packet (type 301) to network.

Next thing after fixing apparent bugs in Director will be Sink (Speaker) rendering the data from Zone Update as audio.

  • Like 1
Link to comment
Share on other sites

Rudimentary implementation of Volume and Balance controls is working:

[07/13/2024 - 04:34:11AM] [NetLink:SOUL:Protocol < (FF06865A)>]: DEBUG - OnLinkReceive event (srcLinkLayer=[NetLink:LinkLayer < (FF06865A)>], inFrame=[Version = 1, destination = None, Source = [NetLink:LinkLayer < (FF0689E2)>], LNET = 0, FrameType = 8028, Payload = [Magic = "SOUL", Version = 1, System = "DefaultSystem", PacketType = 301, Payload = [ZoneName = "A", ListeningSource = [sourceName = "Wattz FM1", SourceType = 1, sourceData = [frequency = 98.000000, Boost = True, StationName = "Diamond City Radio"]], VolumeL = 0.300000, VolumeR = 0.240000]]]).

 

  • Like 1
Link to comment
Share on other sites

5 hours ago, niston said:

https://www.righto.com/2022/01/ibm360model50.html

Click on "link to simulator", hit the "Run" button and watch them blinkenlights 😄 There's a convenient "Step" function, so you can animate it frame by frame, if you want to.

Good resource. Thanks to this resource, I found good register textures and remade the model so that it can be animated. 

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

  • Like 1
Link to comment
Share on other sites

@South8028 A while ago, I had to move the Nixie tube nodes in the Tuner slightly toward the observer, for them to be visible. I now realized I moved them in front of the glass while doing so and tried to correct it. But lo and behold, they became invisible again.

Turns out, I had to modify WATTZ_FM1_v2.bgem used for the glass:

- Set "Env Mask Scale" to 1.0
- Disable "Falloff Enabled"
- Enable "Soft Enabled"

Now the Nixies are back behind the glass and visible from all angles.

Also I managed to fix the ProgramKey indicator. It blinks red at the desired frequency of 2Hz and is clearly observable now. Furthermore I added the same indicator type to the SCAN key: While the Radio Front End is scanning for stations, this new indicator blinks. I may swap this one for a non-blinking version, don't know yet. Changing the color was very easy, as you promised. There were also a bunch of interpolators to edit for the new blinking frequency, but it was a simple job.

Volume and Balance on the preamp also working properly now. Adjusting Balance toward one hand will attenuate the opposite hand channel, from 10 to 50 percent.

I'll start working on the speakers now, so they can play back the RadioSource data from ZoneUpdate packets.

An idea: Can you model some wireless headphones? For headphones, the direct-to-output stereo mode the game engine offers will at least make sense.

Link to comment
Share on other sites

Posted (edited)
1 hour ago, niston said:

@South8028 A while ago, I had to move the Nixie tube nodes in the Tuner slightly toward the observer, for them to be visible. I now realized I moved them in front of the glass while doing so and tried to correct it. But lo and behold, they became invisible again.

Turns out, I had to modify WATTZ_FM1_v2.bgem used for the glass:

- Set "Env Mask Scale" to 1.0
- Disable "Falloff Enabled"
- Enable "Soft Enabled"

Now the Nixies are back behind the glass and visible from all angles.

Also I managed to fix the ProgramKey indicator. It blinks red at the desired frequency of 2Hz and is clearly observable now. Furthermore I added the same indicator type to the SCAN key: While the Radio Front End is scanning for stations, this new indicator blinks. I may swap this one for a non-blinking version, don't know yet. Changing the color was very easy, as you promised. There were also a bunch of interpolators to edit for the new blinking frequency, but it was a simple job.

Volume and Balance on the preamp also working properly now. Adjusting Balance toward one hand will attenuate the opposite hand channel, from 10 to 50 percent.

I'll start working on the speakers now, so they can play back the RadioSource data from ZoneUpdate packets.

An idea: Can you model some wireless headphones? For headphones, the direct-to-output stereo mode the game engine offers will at least make sense.

Yes, you can easily fix animation speed in Nifscope. Simply select a sequence and set the frequency value. 1.00000 is the norm. The higher the value, the faster. Yes. I can make headphones. We can even make wired headphones. We will make them in the form of furniture. Headphones can be connected to the amplifier bs connect point. They will lie, for example, on top of the amplifier, or figure out where they should be. When using furniture, we can make them invisible and replace them with animObject. You just have to figure out what exactly the actor will do. For example, sitting on a chair with headphones on, waving your head and stomping your foot. Or, the actor will stand, swaying and listening to music.

Wireless headphones are easy to make, but not very interesting.

Also, if necessary, we can disassemble the speakers into housings and individual speakers, with different frame rates.

Edited by South8028
Link to comment
Share on other sites

I was rather thinking of an Armor piece, to be worn by the player.

Similar to EngineGaming's Braindance in handling, but letting player listen to whatever is playing on the stereo via equippable headphones. They'd essentially be speakers, from a technical point of view. Could model a stand for them as well, so when not in use, they can be put on display - I already have a script for this. The wireless headphones would work wherever there is NetLink access in the settlement.

 

Link to comment
Share on other sites

Posted (edited)

1972-Spiegel-Christmas-Catalog2017-11-25-19_33_54-768x403.jpg.231fdb2de56ccd4b41de5b3ccfd14cec.jpg

1 hour ago, niston said:

I was rather thinking of an Armor piece, to be worn by the player.

Similar to EngineGaming's Braindance in handling, but letting player listen to whatever is playing on the stereo via equippable headphones. They'd essentially be speakers, from a technical point of view. Could model a stand for them as well, so when not in use, they can be put on display - I already have a script for this. The wireless headphones would work wherever there is NetLink access in the settlement.

 

I hate wireless headphones in real life, but I still have to wear them in the game? Until recently I used wired ones, but people on the street started looking at me like I was an idiot, and I had to switch to wireless ones too. 😁 Okay, I'll make wireless headphones. Tomorrow. Now I was finishing the 360/50 animation. Animated. Now I need to voice this.

 

Edited by South8028
  • Like 1
Link to comment
Share on other sites

You know, you should really label these things HAL.

RobCo could never have produced such sophisticated gear. They were stuck in a bygone era of low capacity holotapes, dumb monochrome terminals and a stupid networking system that cannot distinguish multiple devices of the same type. Not to mention the laughable "security" of their login prompts. They would have long gone bankrupt, were it not for the government cheese granted through defense contracts.

"One Terminal ought to be enough for anybody" - Robert E. House

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...