From 8f37f3fe161891a13a1f94f071a5687bc2ce2cc8 Mon Sep 17 00:00:00 2001 From: atummons <60987561+atummons@users.noreply.github.com> Date: Fri, 4 Oct 2024 12:44:53 -0500 Subject: [PATCH] Fix Broken Images (#2) * Update mode_layering.md Fix image link * Update steppers.md * Update slingshots.md * Update mma8451.md * Update showcreator.md * Update lights.md * Update flashers.md * Update optos.md * Update quad.md * Update points.md * Update easing.md * Update types.md * Update rectangle.md * Update servos.md * Update positioning.md * Update leds.md * Update bitmap_fonts.md * Update connection.md * Update i2c.md * Update connecting.md * Update opacity.md * Update split_screen.md * Update vari_targets.md * Update drivers.md * Update layers.md * Update smartmatrix.md * Update win_x64.md * Update win_x86.md * Update up_down_ramps.md * Update line.md * Update ellipse.md * Update lights_versus_leds.md * Update connecting.md * Update rollover_switches.md * Update stationary_targets.md * Update easing_config.md * Update power_entry.md * Update mechanical_switches.md * Update dmd.md * Update gamma_correction.md * Update smbus.md * Update center_post.md * Update config.md * Update service_and_door_switches.md * Update drop_target_bank.md * Update switches.md * Update dmd.md * Update adding_dot_look_to_lcd.md * Update drivers.md * Update skill_shot.md * Update classic_single_ball.md * Update switches_p3_roc.md * Update auto_manual.md * Update configuring_bonus.md * Update pololu_maestro.md * Update architecture.md * Update mechanical_no_switch.md * Update coil_fired.md * Update two_coil_one_switch.md * Update mechanical_with_switch.md * Update classic_single_ball_no_shooter_lane.md * Update media_controller.md * Update index.md * Update index.md * Update index.md * Update index.md * Update index.md * Update index.md * Update steppers.md * Update index.md * Update index.md * Update index.md * Update index.md * Update dmd_fonts.md --- docs/config/instructions/gamma_correction.md | 4 +- docs/game_design/mode_layering.md | 2 +- docs/game_logic/ball_saves/center_post.md | 2 +- docs/game_logic/bonus/configuring_bonus.md | 2 +- docs/game_logic/skill_shot.md | 2 +- docs/hardware/fast/switches.md | 2 +- docs/hardware/lisy/connection.md | 8 +-- docs/hardware/lisy/index.md | 2 +- docs/hardware/mma8451.md | 2 +- docs/hardware/multimorphic/connecting.md | 12 ++-- docs/hardware/multimorphic/dmd.md | 4 +- docs/hardware/multimorphic/i2c.md | 2 +- docs/hardware/multimorphic/power_entry.md | 2 +- docs/hardware/multimorphic/switches_p3_roc.md | 4 +- docs/hardware/multimorphic/win_x64.md | 2 +- docs/hardware/multimorphic/win_x86.md | 2 +- docs/hardware/opp/cobrapin/index.md | 28 ++++---- docs/hardware/opp/oppcombo/index.md | 10 +-- docs/hardware/pkone/connecting.md | 2 +- docs/hardware/pkone/drivers.md | 2 +- docs/hardware/pkone/lights.md | 2 +- docs/hardware/pkone/servos.md | 2 +- docs/hardware/pololu_maestro.md | 2 +- docs/hardware/smartmatrix.md | 12 ++-- docs/hardware/smbus.md | 2 +- docs/hardware/spike/config.md | 2 +- docs/hardware/spike/drivers.md | 2 +- docs/hardware/spike/leds.md | 4 +- docs/hardware/spike/steppers.md | 2 +- docs/mc/displays/adding_dot_look_to_lcd.md | 6 +- docs/mc/displays/architecture.md | 2 +- docs/mc/displays/dmd.md | 6 +- docs/mc/displays/types.md | 10 +-- docs/mc/slides/index.md | 4 +- docs/mc/slides/split_screen.md | 6 +- docs/mc/widgets/bitmap_fonts.md | 4 +- docs/mc/widgets/dmd_fonts.md | 8 +-- docs/mc/widgets/easing.md | 72 +++++++++---------- docs/mc/widgets/easing_config.md | 4 +- docs/mc/widgets/ellipse.md | 2 +- docs/mc/widgets/layers.md | 4 +- docs/mc/widgets/line.md | 2 +- docs/mc/widgets/opacity.md | 2 +- docs/mc/widgets/points.md | 2 +- docs/mc/widgets/positioning.md | 14 ++-- docs/mc/widgets/quad.md | 2 +- docs/mc/widgets/rectangle.md | 2 +- docs/mechs/diverters/index.md | 8 +-- docs/mechs/diverters/up_down_ramps.md | 2 +- docs/mechs/lights/flashers.md | 4 +- docs/mechs/lights/lights_versus_leds.md | 4 +- docs/mechs/magnets/index.md | 6 +- docs/mechs/plungers/auto_manual.md | 6 +- docs/mechs/plungers/coil_fired.md | 4 +- docs/mechs/plungers/index.md | 10 +-- docs/mechs/plungers/mechanical_no_switch.md | 2 +- docs/mechs/plungers/mechanical_with_switch.md | 2 +- docs/mechs/pop_bumpers/index.md | 8 ++- docs/mechs/servos/index.md | 2 +- docs/mechs/slingshots.md | 4 +- docs/mechs/steppers.md | 4 +- docs/mechs/switches/mechanical_switches.md | 4 +- docs/mechs/switches/optos.md | 8 +-- docs/mechs/switches/rollover_switches.md | 2 +- .../switches/service_and_door_switches.md | 2 +- .../targets/drop_targets/drop_target_bank.md | 2 +- docs/mechs/targets/stationary_targets.md | 2 +- docs/mechs/targets/vari_targets.md | 6 +- docs/mechs/troughs/classic_single_ball.md | 4 +- .../classic_single_ball_no_shooter_lane.md | 2 +- docs/mechs/troughs/index.md | 12 ++-- docs/mechs/troughs/two_coil_one_switch.md | 4 +- docs/start/media_controller.md | 2 +- docs/tools/showcreator.md | 8 +-- 74 files changed, 203 insertions(+), 199 deletions(-) diff --git a/docs/config/instructions/gamma_correction.md b/docs/config/instructions/gamma_correction.md index f489bd2fb1..81243a5793 100644 --- a/docs/config/instructions/gamma_correction.md +++ b/docs/config/instructions/gamma_correction.md @@ -21,12 +21,12 @@ looks fully bright, and that 50% looks like 50%, etc. Here is a screenshot of a slide which has 16 bars which fade from off to fully white, in a more-or-less even fashion: -![image](/config/images/good_gamma.png) +![image](../images/good_gamma.png) However if you show this slide on your physical DMD with no gamma correction, it looks something like this: -![image](/config/images/bad_gamma.png) +![image](../images/bad_gamma.png) Even though the individual pixels are showing their "correct" brightness, the human eye can't really tell a different between 50% and diff --git a/docs/game_design/mode_layering.md b/docs/game_design/mode_layering.md index 5477f30b15..ca10d2f4b4 100644 --- a/docs/game_design/mode_layering.md +++ b/docs/game_design/mode_layering.md @@ -81,7 +81,7 @@ default, the global mode starts when the base mode starts and the field mode starts when the global mode starts. As a result, the typical player turn starts with field mode (a.k.a. on an open playfield). -![image](/game_design/images/mode_layering.png) +![image](images/mode_layering.png) *Field and Mission modes are mutually exclusive:* the field mode stops when a mission mode starts, and starts again when the mission mode diff --git a/docs/game_logic/ball_saves/center_post.md b/docs/game_logic/ball_saves/center_post.md index 7795830ee2..c6dc3f30ca 100644 --- a/docs/game_logic/ball_saves/center_post.md +++ b/docs/game_logic/ball_saves/center_post.md @@ -8,7 +8,7 @@ title: Center Post Ball Save Some machines have a mechanical ball save called center post. It pops up between the flippers and prevents the ball from draining. -![image](/game_logic/images/center_post.jpg) +![image](../images/center_post.jpg) Video about center posts: diff --git a/docs/game_logic/bonus/configuring_bonus.md b/docs/game_logic/bonus/configuring_bonus.md index d46d0c40a5..920e7d3795 100644 --- a/docs/game_logic/bonus/configuring_bonus.md +++ b/docs/game_logic/bonus/configuring_bonus.md @@ -17,7 +17,7 @@ Even though the bonus mode is built-in, you'll still need to add a It should look something like this: -![image](/game_logic/images/bonus_folder.png) +![image](../images/bonus_folder.png) ## 2. Add the bonus mode to your machine-wide modes list diff --git a/docs/game_logic/skill_shot.md b/docs/game_logic/skill_shot.md index f3ad6cd2bb..277c18477c 100644 --- a/docs/game_logic/skill_shot.md +++ b/docs/game_logic/skill_shot.md @@ -176,7 +176,7 @@ the group posts `skill_shot_lit_hit` and `skill_shot_unlit_hit` when a unlit shot is hit. To prevent races between the two events we use a state_machine called `skill_shot_success` which has three states: -![image](/game_logic/images/skill_shot_state_machine.png) +![image](/docs/game_logic/images/skill_shot_state_machine.png) When the mode started it starts at `start`. Then when either `skill_shot_lit_hit` or `skill_shot_unlit_hit` are posted in transitions diff --git a/docs/hardware/fast/switches.md b/docs/hardware/fast/switches.md index fc1976553b..933acb0730 100644 --- a/docs/hardware/fast/switches.md +++ b/docs/hardware/fast/switches.md @@ -21,7 +21,7 @@ get with FAST hardware that is discussed here. When you're using FAST IO boards, switches plug into individual IO boards. Then the IO boards are connected together in a loop. -![image](/hardware/images/fast-io-3208.png) +![image](../images/fast-io-3208.png) The `number:` setting for each switch is its board's position number in the chain, then the dash, then the switch input number. Note that the diff --git a/docs/hardware/lisy/connection.md b/docs/hardware/lisy/connection.md index f2121e97e5..ceafb68072 100644 --- a/docs/hardware/lisy/connection.md +++ b/docs/hardware/lisy/connection.md @@ -17,7 +17,7 @@ Gottlieb CPU board with the "LISY1" board. details. Basically you replace the MPU with the LISY board. You can still play the original ROM using PinMAME on LISY. -![image](/hardware/images/lisy80_board.jpg) +![image](/docs/hardware/images/lisy80_board.jpg) More details can be found in the [LISY user manual](http://www.lisy80.com/english/documentation-lisy/). @@ -44,7 +44,7 @@ b. Run MPF on the LISY hardware directly ("master" mode). See the following image for an architecture overview: -![image](/hardware/images/lisy_mpf_overview.jpg) +![image](/docs/hardware/images/lisy_mpf_overview.jpg) If you want to run MPF on the LISY controller itself, set DIP 4 (option1) and DIP 8 (autostart) to 'ON' and all other DIPs on that @@ -63,7 +63,7 @@ with the host PC running MPF, set DIP 2 to 'ON' for network mode or order to be able to reboot, as it will power the Raspberry Pi over the USB connection. -![image](/hardware/images/LISY_modes.png) +![image](/docs/hardware/images/LISY_modes.png) ## 3. Configure your Game @@ -130,7 +130,7 @@ needed, a "normal" USB charging cable (Micro-USB cable) will do the job. Once connected to the host computer, it will (hopefully) identify a new serial device. This is usually `COMX` on windows: -![image](/hardware/images/lisy_windows_com_port.png) +![image](/docs/hardware/images/lisy_windows_com_port.png) Or `/dev/ttyACMX` on Linux: diff --git a/docs/hardware/lisy/index.md b/docs/hardware/lisy/index.md index 9abdc0679b..64ab9ba669 100644 --- a/docs/hardware/lisy/index.md +++ b/docs/hardware/lisy/index.md @@ -44,7 +44,7 @@ b. Run MPF on the LISY hardware directly ("master" mode). See the following image for an architecture overview: -![image](/hardware/images/lisy_mpf_overview.jpg) +![image](../images/lisy_mpf_overview.jpg) LISY can controll all features of your Gottlieb System1/80 machine. This includes: diff --git a/docs/hardware/mma8451.md b/docs/hardware/mma8451.md index c356cb6de9..c55f22e82b 100644 --- a/docs/hardware/mma8451.md +++ b/docs/hardware/mma8451.md @@ -32,7 +32,7 @@ This will configure an MMA8451 on I2C bus 1 with address 0x1D (29 decimal which is the default for this device). The exact numbering depends on your i2c platform. -![image](/hardware/images/mma8451-i2c-usb-accelerometer.jpg) +![image](images/mma8451-i2c-usb-accelerometer.jpg) The device in the picture is using [smbus on linux](smbus.md) diff --git a/docs/hardware/multimorphic/connecting.md b/docs/hardware/multimorphic/connecting.md index 5d0a69c931..797d03d82b 100644 --- a/docs/hardware/multimorphic/connecting.md +++ b/docs/hardware/multimorphic/connecting.md @@ -14,7 +14,7 @@ Wiki](http://pinballmakers.com/wiki/index.php/P-ROC_Main_Page). If you got a P-Roc just connect it to your computer using USB. -![image](/hardware/images/multimorphic_p_roc.png) +![image](../images/multimorphic_p_roc.png) Then connect switches and driver according to the manual (see [leds](../../machines/index.md) for @@ -28,20 +28,20 @@ it is connected correctly. If you got a P3-Roc just connect it to your computer using USB. -![image](/hardware/images/multimorphic_p3_roc.png) +![image](../images/multimorphic_p3_roc.png) Connect all your SW-16 boards to the switch bus and all your PD-16 and PD-8x8 boards to your driver bus. Use twisted wires but connect + to + and - to - on all nodes. -![image](/hardware/images/multimorphic_p3_roc_wireing.jpg) +![image](../images/multimorphic_p3_roc_wireing.jpg) [mpf hardware scan](../../running/commands/hardware.md) will show the firmware version and revision of your P3-Roc if it is connected correctly. ### SW-16 -![image](/hardware/images/multimorphic_SW-16.png) +![image](../images/multimorphic_SW-16.png) Set a unique address on every SW-16 board on your bus. Those addresses can overlap with the driver addresses. It does not matter on which of @@ -64,7 +64,7 @@ SW-16 boards found: ### PD-16/PD-8x8 -![image](/hardware/images/multimorphic_PD-16.png) +![image](../images/multimorphic_PD-16.png) Set a unique address on every PD-16/PD-8x8 board on your bus. Those addresses can overlap with the switch addresses. However, they overlap @@ -79,7 +79,7 @@ communication is one-way only. ### PD-LED -![image](/hardware/images/multimorphic_PD-LED.png) +![image](../images/multimorphic_PD-LED.png) Set a unique address on every PD-LED board on your bus. Those addresses can overlap with the switch addresses. However, they overlap with the diff --git a/docs/hardware/multimorphic/dmd.md b/docs/hardware/multimorphic/dmd.md index e79faa1ef5..f2593e4afc 100644 --- a/docs/hardware/multimorphic/dmd.md +++ b/docs/hardware/multimorphic/dmd.md @@ -14,7 +14,7 @@ The P-ROC can drive a traditional single-color pinball DMD via the 14-pin DMD connector cable that's been in most pinball machines for the past 25 years, like this: -![image](/hardware/images/display_mono_dmd.jpg) +![image](../images/display_mono_dmd.jpg) !!! note @@ -25,7 +25,7 @@ past 25 years, like this: ## 1. Connect your hardware -![image](/hardware/images/physical_dmd_in_backbox.jpg) +![image](../images/physical_dmd_in_backbox.jpg) ## 2. Add a physical DMD device entry diff --git a/docs/hardware/multimorphic/i2c.md b/docs/hardware/multimorphic/i2c.md index 8ec05d7448..385e210121 100644 --- a/docs/hardware/multimorphic/i2c.md +++ b/docs/hardware/multimorphic/i2c.md @@ -12,7 +12,7 @@ Related Config File Sections: The P3-ROC contains an I2C port (J17) which is accessible to MPF. You can use this port to control any I2C-based device. -![image](/hardware/images/multimorphic_p3_roc.png) +![image](/docs/hardware/images/multimorphic_p3_roc.png) You need to connect SDA, SCL and ground. You may not need the 3.3V from the P3-ROC as your controller might be a different voltage (which you diff --git a/docs/hardware/multimorphic/power_entry.md b/docs/hardware/multimorphic/power_entry.md index 2b39f4743f..b219123035 100644 --- a/docs/hardware/multimorphic/power_entry.md +++ b/docs/hardware/multimorphic/power_entry.md @@ -9,7 +9,7 @@ This board can be used to fan out your power rails. See [Voltages and Power in Pinball Machines](../voltages_and_power/index.md) for details. -![image](/hardware/images/multimorphic_Power_Entry.png) +![image](../images/multimorphic_Power_Entry.png) The Multimorphic Power Filter board serves four purposes. 1. It serves as a central connection point for 230V/110V AC and all your PSUs using diff --git a/docs/hardware/multimorphic/switches_p3_roc.md b/docs/hardware/multimorphic/switches_p3_roc.md index 02de3a9942..3e460a44a4 100644 --- a/docs/hardware/multimorphic/switches_p3_roc.md +++ b/docs/hardware/multimorphic/switches_p3_roc.md @@ -22,7 +22,7 @@ itself. Instead, you add SW-16 boards which each have 16 direct switch inputs. (e.g. there is no switch matrix.) You can connect up to 16 SW-16s to support as many as 256 switches. -![image](/hardware/images/multimorphic_SW-16.png) +![image](../images/multimorphic_SW-16.png) Each SW-16 has a unique `board number` which is set using DIP switches (find that out now). On each board there are two `banks` (A and B) of 8 @@ -89,7 +89,7 @@ MPF. * Local Inputs - Alternatively you can use them as direct local inputs (and the burst drivers as outputs; see [How to configure coils/drivers/magnets (P-ROC/P3-ROC)](drivers.md) section for details). -![image](/hardware/images/multimorphic_p3_roc.png) +![image](../images/multimorphic_p3_roc.png) ### Burst Switches as Burst Optos diff --git a/docs/hardware/multimorphic/win_x64.md b/docs/hardware/multimorphic/win_x64.md index dc18cd45fa..b91a9ab326 100644 --- a/docs/hardware/multimorphic/win_x64.md +++ b/docs/hardware/multimorphic/win_x64.md @@ -25,7 +25,7 @@ shot below. That should be ok. Download and run the setup executable from the "1" link in the screen shot. -![image](/hardware/images/ftdi_x64.jpg) +![image](/docs/hardware/images/ftdi_x64.jpg) ## 2. Now download and unzip the other package diff --git a/docs/hardware/multimorphic/win_x86.md b/docs/hardware/multimorphic/win_x86.md index 56806fe767..25c993cb91 100644 --- a/docs/hardware/multimorphic/win_x86.md +++ b/docs/hardware/multimorphic/win_x86.md @@ -22,7 +22,7 @@ Here's a screen shot of the download section of that page. Note that the actual version number of the driver might be newer that the screen shot below. That should be ok. -![image](/hardware/images/ftdi_x86.jpg) +![image](/docs/hardware/images/ftdi_x86.jpg) Download and run the setup executable from the "1" link in the screen shot. (We like to use that because it's easier than the manual process diff --git a/docs/hardware/opp/cobrapin/index.md b/docs/hardware/opp/cobrapin/index.md index 9ee4f75b8f..0a9061a060 100644 --- a/docs/hardware/opp/cobrapin/index.md +++ b/docs/hardware/opp/cobrapin/index.md @@ -7,7 +7,7 @@ title: CobraPin Pinball Controller powered by OPP --8<-- "hardware_platform.md" -![image](/hardware/images/CobraPinV0_2_isoSmall.jpg) +![image](/docs/hardware/images/CobraPinV0_2_isoSmall.jpg) Features: @@ -41,7 +41,7 @@ Video about cobrapin extension board: ## Power Input and Filter -![image](/hardware/images/CobraPinV0_2_VIN.jpg) +![image](/docs/hardware/images/CobraPinV0_2_VIN.jpg) **J9:** @@ -58,7 +58,7 @@ connectors. ## Switch Inputs -![image](/hardware/images/CobraPinV0_2_switches.jpg) +![image](/docs/hardware/images/CobraPinV0_2_switches.jpg) **J1, J2, J3:** @@ -79,14 +79,14 @@ connectors. For example Molex KK254 series available for AWG 30-22. Each connect for the direct input return. If you measure the voltage between GND and a switch (in below picture 0-0-16) you should measure 3.3V. -![image](/hardware/images/Cobra_Voltage_Switch.jpg) +![image](/docs/hardware/images/Cobra_Voltage_Switch.jpg) For that to measure only the micro controllers need to be powered up, no need to apply any other voltage on the Cobra board. To perform a simple test connect any kind of switch to one of the inputs and setup a little mpf test configuration. -![image](/hardware/images/Cobra_Switch_connected.jpg) +![image](/docs/hardware/images/Cobra_Switch_connected.jpg) Do not apply any voltage to the switches, most likely that will destroy your CPU. For further details and fully working Cobra board @@ -97,7 +97,7 @@ section below. ## Solenoid Outputs -![image](/hardware/images/CobraPinV0_2_solenoids.jpg) +![image](/docs/hardware/images/CobraPinV0_2_solenoids.jpg) **J6, J7, J8:** @@ -123,7 +123,7 @@ must be controlled by switch with number `0-a-b`. Each bank has an LED next to it to indicate if that bank has power. Check these if you are concerned you have blown a fuse. -![image](/hardware/images/Cobra_Coils_LED_Power.jpg) +![image](/docs/hardware/images/Cobra_Coils_LED_Power.jpg) In above picture you see that the LED for bank A is alight but not for bank B. In order to have the LED alight you only need to have connected @@ -138,7 +138,7 @@ voltage power or without the coils plugged in. Using these LEDs, you can verify that each output is being driven correctly, in the picture below coil 1-0-1 is being driven at this very moment. -![image](/hardware/images/Cobra_Coils_LED_Switch.jpg) +![image](/docs/hardware/images/Cobra_Coils_LED_Switch.jpg) To run the above test, there is no need for a high voltage power supply neither for any coil. Only the mirco controllers need to be powered up. @@ -184,7 +184,7 @@ To have a fully working example for setting up autofire coils see the ## Solenoid Power Output and Fuses -![image](/hardware/images/CobraPinV0_2_HVout.jpg) +![image](/docs/hardware/images/CobraPinV0_2_HVout.jpg) **J13:** @@ -205,7 +205,7 @@ The fuses are 5x20mm. Each fuse provides power to a bank of 8 solenoids. ## Neopixel Support -![image](/hardware/images/CobraPinV0_2_NEO.jpg) +![image](/docs/hardware/images/CobraPinV0_2_NEO.jpg) **J10:** @@ -227,7 +227,7 @@ The connectors J10, J11, J12 and J14 are JST connectors VH style. There are lots of Neopixels which come with a JST connector SM style. You might want to craft a little converter cable in such a case. -![image](/hardware/images/Cobra_Neopixel_JST_adapter_VH_SM.jpg) +![image](/docs/hardware/images/Cobra_Neopixel_JST_adapter_VH_SM.jpg) There are two neopixel chains that support 256 RGB pixels each for a total of 512. RGBW pixels are also possible, but the number may be @@ -240,7 +240,7 @@ fuse and are providing power for neopixels. For the LED to light up there is no need to run any MPF configuration, you don't even have to power up the micro controllers. -![image](/hardware/images/Cobra_Power_LED_Neopixel.jpg) +![image](/docs/hardware/images/Cobra_Power_LED_Neopixel.jpg) When you order the micro controllers you have various options, one option to choose from is Regular vs NoGlow. If you order the Regular @@ -248,7 +248,7 @@ version then after power is provided for the Neopixel and the micro controllers are powered up (still no need to run any MPF on them), the LEDs of your strip will glow blue, which is a good first test. -![image](/hardware/images/Cobra_Neopixel_blue_glow.jpg) +![image](/docs/hardware/images/Cobra_Neopixel_blue_glow.jpg) In order to addess the LEDs in MPF you need to know their address @@ -268,7 +268,7 @@ generic LED section [LEDs](../../../mechs/lights/index.md) where as well the mor ## Microcontrollers -![image](/hardware/images/CobraPinV0_2_STM32.jpg) +![image](/docs/hardware/images/CobraPinV0_2_STM32.jpg) The brains of the CobraPin are two STM32 microcontroller boards programmed with OPP firmware. They are connected to the host computer diff --git a/docs/hardware/opp/oppcombo/index.md b/docs/hardware/opp/oppcombo/index.md index f1358e4a70..7abd18c19a 100644 --- a/docs/hardware/opp/oppcombo/index.md +++ b/docs/hardware/opp/oppcombo/index.md @@ -7,9 +7,9 @@ title: OPP EM Combo boards --8<-- "hardware_platform.md" -![image](/hardware/images/O16I16_comps.jpg) +![image](/docs/hardware/images/O16I16_comps.jpg) -![image](/hardware/images/O32_comps.jpg) +![image](/docs/hardware/images/O32_comps.jpg) The aim of this project is to provide cheap hardware to control EM pinball machines: @@ -30,9 +30,9 @@ The size of the board is about 150 x 125 mm. Several boards are required to drive an EM machine. According to the complexity and your personal taste, 3-4 to drive the play field, 2-3 to drive the light box. -![image](/hardware/images/fast_draw_lb.jpg) +![image](/docs/hardware/images/fast_draw_lb.jpg) -![image](/hardware/images/fast_draw_pf.jpg) +![image](/docs/hardware/images/fast_draw_pf.jpg) ## Configuration @@ -85,6 +85,6 @@ In the above example one would do: With those boards, I digitized a 1975 Gottlieb Fast Draw, which was presented to the [Pontacq Pinball Show](https://www.facebook.com/groups/154388563388625) on June 1rst-2nd, 2024, South of France, where it ran 375 plays without any software problem. -![image](/hardware/images/pontacq.jpg) +![image](/docs/hardware/images/pontacq.jpg) diff --git a/docs/hardware/pkone/connecting.md b/docs/hardware/pkone/connecting.md index 51f84fd22f..3d470de46a 100644 --- a/docs/hardware/pkone/connecting.md +++ b/docs/hardware/pkone/connecting.md @@ -12,7 +12,7 @@ roughly covers connecting the bus between the boards. Connect your PKONE NANO controller to your PC using USB. -![image](/hardware/images/pkone-nano.png) +![image](/docs/hardware/images/pkone-nano.png) Then connect the OUT port of your NANO to the IN port of your first board (Extension or Lightshow). Consequently, connect the OUT port of diff --git a/docs/hardware/pkone/drivers.md b/docs/hardware/pkone/drivers.md index da010e857c..afa2aced90 100644 --- a/docs/hardware/pkone/drivers.md +++ b/docs/hardware/pkone/drivers.md @@ -26,7 +26,7 @@ When you're using PKONE Extension boards, drivers plug into individual Extension boards. Then the Extension boards are connected together in a chain to the controller. -![image](/hardware/images/pkone-extension.png) +![image](../images/pkone-extension.png) The `number:` setting for each coil/driver is its board's Address ID number in the PKONE chain, then the dash, then the coil/driver output diff --git a/docs/hardware/pkone/lights.md b/docs/hardware/pkone/lights.md index c7abb86ec4..a076de80f0 100644 --- a/docs/hardware/pkone/lights.md +++ b/docs/hardware/pkone/lights.md @@ -21,7 +21,7 @@ individual Lightshow boards. Then the Lightshow boards are connected together in a chain with other add-on boards (such as PKONE Extension boards) to the controller. -![image](/hardware/images/pkone-lightshow.png) +![image](/docs/hardware/images/pkone-lightshow.png) The `number:` setting for each simple LED is its board's Address ID number in the PKONE chain, then the dash, then the simple LED output diff --git a/docs/hardware/pkone/servos.md b/docs/hardware/pkone/servos.md index 2fc4ceaa9d..d70b371192 100644 --- a/docs/hardware/pkone/servos.md +++ b/docs/hardware/pkone/servos.md @@ -23,7 +23,7 @@ When you're using PKONE Extension boards, coils plug into individual Extension boards. Then the Extension boards are connected together in a chain to the controller. -![image](/hardware/images/pkone-extension.png) +![image](/docs/hardware/images/pkone-extension.png) The `number:` setting for each servo is its board's Address ID number in the PKONE chain, then the dash, then the servo output number (11-14). diff --git a/docs/hardware/pololu_maestro.md b/docs/hardware/pololu_maestro.md index ba77ec2f25..6f662bd6e0 100644 --- a/docs/hardware/pololu_maestro.md +++ b/docs/hardware/pololu_maestro.md @@ -14,7 +14,7 @@ MPF supports servos connected to Pololu Maestro servo controllers. Each Maestro can control multiple servos, with models that control 6, 12, 18, or 24 servos. -![image](/hardware/images/pololu_maestro.jpg) +![image](/docs/hardware/images/pololu_maestro.jpg) Here is an explanation video by the pinball amigos on how to setup a pololu maestro (and more): diff --git a/docs/hardware/smartmatrix.md b/docs/hardware/smartmatrix.md index d6f53b167b..bf68aa7ec2 100644 --- a/docs/hardware/smartmatrix.md +++ b/docs/hardware/smartmatrix.md @@ -29,7 +29,7 @@ other options that MPF supports is available in the Here's an image of the SmartMatrix RGB DMD in action: -![image](/hardware/images/display_rgb_dmd.jpg) +![image](/docs/hardware/images/display_rgb_dmd.jpg) And a video which explains it all: @@ -39,7 +39,7 @@ And a video which explains it all: The following diagram shows how all the components fit together: -![image](/hardware/images/smartmatrix_architecture.png) +![image](/docs/hardware/images/smartmatrix_architecture.png) ## 1. Buy all the parts you need @@ -87,7 +87,7 @@ bit-shifting of data needed to control these panels. Here's a Teensy: -![image](/hardware/images/teensy.jpg) +![image](/docs/hardware/images/teensy.jpg) The software to run the Teensy is open source (more on that in Step 3) and the Teensy has a USB port which you connect to your computer which @@ -103,13 +103,13 @@ The SmartMatrix shield is a "dumb" device that basically just connects the Teensy's GPIO pins to the 16-pin ribbon cable that drives the displays. -![image](/hardware/images/smartmatrix_shield.jpg) +![image](/docs/hardware/images/smartmatrix_shield.jpg) The Teensy mounts onto the SmartMatrix shield, creating a single unit which accepts data via USB on one end and spits out the 16-pin signal for the display panels on the other. -![image](/hardware/images/smartmatrix_shield_with_teensy.jpg) +![image](/docs/hardware/images/smartmatrix_shield_with_teensy.jpg) ### (4) The Power Supply @@ -124,7 +124,7 @@ If you're ordering your RGB LED display panels from FAST Pinball, you can also order a [5v, 10A power supply from them for \$19](https://squareup.com/store/fast-pinball-llc/item/five-volt-ten-amp-switching-power-supply). -![image](/hardware/images/5v10a_psu.jpg) +![image](/docs/hardware/images/5v10a_psu.jpg) An ATX computer power supply will probably have a decent amount of amps also, so that could be an option too, just check the specs. Any other 5V diff --git a/docs/hardware/smbus.md b/docs/hardware/smbus.md index f3b3dc29fd..00eb028fa1 100644 --- a/docs/hardware/smbus.md +++ b/docs/hardware/smbus.md @@ -38,7 +38,7 @@ Install `smbus2_asyncio` via pip: This is an adafruit trinket used as USB-I2C adapter for an [MMA8451-based accelerometer](mma8451.md): -![image](/hardware/images/mma8451-i2c-usb-accelerometer.jpg) +![image](/docs/hardware/images/mma8451-i2c-usb-accelerometer.jpg) ## 3. Connect your hardware diff --git a/docs/hardware/spike/config.md b/docs/hardware/spike/config.md index 9864cc6923..1061c14083 100644 --- a/docs/hardware/spike/config.md +++ b/docs/hardware/spike/config.md @@ -74,7 +74,7 @@ nodes: can get this from the manual. Here's an example from Wrestlemania Pro: - ![image](/hardware/images/spike_node_table.png) + ![image](../images/spike_node_table.png)   Only map the node boards and ignore the extension boards because those   are transparent to MPF. Just consider 8 and 8a/8b to be the diff --git a/docs/hardware/spike/drivers.md b/docs/hardware/spike/drivers.md index be22c5ac0f..f44475c735 100644 --- a/docs/hardware/spike/drivers.md +++ b/docs/hardware/spike/drivers.md @@ -26,7 +26,7 @@ The `number:` setting for each driver is a combination of the node it's connected to and its address from the manual. For example, here's the driver reference table from Page 11 of the Wrestlemania Pro manual: -![image](/hardware/images/spike_driver_table.jpg) +![image](../images/spike_driver_table.jpg) The address for each driver is in the highlighted column. To enter the number for the driver into MPF, remove the middle "DR" letters so you diff --git a/docs/hardware/spike/leds.md b/docs/hardware/spike/leds.md index 6017e0afa9..c3765cf55b 100644 --- a/docs/hardware/spike/leds.md +++ b/docs/hardware/spike/leds.md @@ -45,7 +45,7 @@ Pretty much you just look up the number in the manual for your machine and then enter it without any letters. For example, here is (part of) the lighting chart from Wrestlemania Pro: -![image](/hardware/images/spike_light_table.jpg) +![image](/docs/hardware/images/spike_light_table.jpg) Use the address column (highlighted in yellow) to get the numbers for each LED. Remove the "LP" letters, and also remove any lowercase @@ -98,7 +98,7 @@ into single RGB objects. Here's an example from the Wrestlemania Pro manual: -![image](/hardware/images/spike_rgb_light_table.jpg) +![image](/docs/hardware/images/spike_rgb_light_table.jpg) You could enter the three channels as three separate lights in the `lights:` section of your machine config. However, that would complicate diff --git a/docs/hardware/spike/steppers.md b/docs/hardware/spike/steppers.md index a4e4fd164b..b0b1fcd0aa 100644 --- a/docs/hardware/spike/steppers.md +++ b/docs/hardware/spike/steppers.md @@ -44,7 +44,7 @@ number once. Then you need to look up the motor reference number in your manual. This is an example from Game of Thrones LE: -![image](/hardware/images/spike_stepper_table.png) +![image](../images/spike_stepper_table.png) We are interested in `10-LP-10`. This is used as `light_number` above. `10-LP-11` is not used and we guess that Spike automatically uses the diff --git a/docs/mc/displays/adding_dot_look_to_lcd.md b/docs/mc/displays/adding_dot_look_to_lcd.md index 89d9554181..8a42280024 100644 --- a/docs/mc/displays/adding_dot_look_to_lcd.md +++ b/docs/mc/displays/adding_dot_look_to_lcd.md @@ -8,7 +8,7 @@ title: How to give your on-screen window the DMD "dot look This guide will show you how to configure a full screen "dot look" display, like this: -![image](/mc/images/dot_look_full_screen.png) +![image](../images/dot_look_full_screen.png) The final sections of the machine config to make this happen are here: @@ -100,7 +100,7 @@ resulting in a better overall image. For example, if we zoom in on the 120x90 virtual DMD being shown on an 800x600 window, we'll see that it looks like this: -![image](/mc/images/dot_look_zoom_in_6_to_1.png) +![image](../images/dot_look_zoom_in_6_to_1.png) This works because there is about a 6x6 grid of pixels in the window for each virtual pixel in the DMD. @@ -254,7 +254,7 @@ Also, you don't have to make the virtual DMD be the full size of the display. For example, if you set your dmd display to be 128x32 and then set the color_dmd widget to be 640x160, you'll get a display like this: -![image](/mc/images/display_color_dmd2.png) +![image](../images/display_color_dmd2.png) You can also use the [widget sizing and positioning](../widgets/positioning.md) to create a DMD widget that is pre-positioned at a certain diff --git a/docs/mc/displays/architecture.md b/docs/mc/displays/architecture.md index e4f642b7bd..080abff9cd 100644 --- a/docs/mc/displays/architecture.md +++ b/docs/mc/displays/architecture.md @@ -22,7 +22,7 @@ step-by-step tutorial to get your display up and running just with a few config file entries.) But as you start to create more advanced display effects, it will be helpful to understand how everything fits together. -![image](/mc/images/display_architecture.png) +![image](../images/display_architecture.png) The major components of the MPF Media Controller's display system are: diff --git a/docs/mc/displays/dmd.md b/docs/mc/displays/dmd.md index cd6695ecbe..e95da658b3 100644 --- a/docs/mc/displays/dmd.md +++ b/docs/mc/displays/dmd.md @@ -8,7 +8,7 @@ title: Using a traditional (single color) physical DMD This guide will show you how to use a traditional, physical DMD with MPF, like this: -![image](/mc/images/display_mono_dmd.jpg) +![image](../images/display_mono_dmd.jpg) This is supported for all [Monochome DMD platforms](../../hardware/dmd_platforms.md). @@ -16,7 +16,7 @@ This is supported for all It will also show you how to create an on-screen popup window which will show the contents of the DMD, like this (with a blank DMD): -![image](/mc/images/on_screen_basic_dmd_window.png) +![image](../images/on_screen_basic_dmd_window.png) If you want to use a physical DMD without the on-screen equivalent, we'll show you how to do that at the end. @@ -36,7 +36,7 @@ This guide explains how to config physical single-color (mono) DMDs. These are DMDs that are connected to your FAST Pinball or P-ROC controller via the 14-pin ribbon cable, like this: -![image](/mc/images/physical_dmd_in_backbox.jpg) +![image](../images/physical_dmd_in_backbox.jpg) It makes no difference whether you're using an LED or an original plasma gas DMD. (Also it doesn't matter what color it is.) diff --git a/docs/mc/displays/types.md b/docs/mc/displays/types.md index 699cece3b6..e010199ad0 100644 --- a/docs/mc/displays/types.md +++ b/docs/mc/displays/types.md @@ -35,28 +35,28 @@ manual programming. Here's a traditional [single-color / mono DMD](dmd.md): -![image](/mc/images/display_mono_dmd.jpg) +![image](/docs/mc/images/display_mono_dmd.jpg) Here's an on-screen window (or what many people called an "LCD" display. In this case, it's showing on single [color DMD](rgb_dmd.md) virtually with no "dot" filter applied, along with other on-screen content: -![image](/mc/images/display_window.jpg) +![image](/docs/mc/images/display_window.jpg) Here's a "color" DMD on an LCD monitor. It's showing a 128x32 window of color content, with a "dot look" filter to make it look like dots. -![image](/mc/images/display_color_dmd.jpg) +![image](/docs/mc/images/display_color_dmd.jpg) Here's a full-size window with the dot filter applied: -![image](/mc/images/dot_look_full_screen.png) +![image](/docs/mc/images/dot_look_full_screen.png) Here's a full-color RGB DMD LED matrix. (So it's like a color DMD, but a matrix of 2.5mm RGB LEDs rather than an LCD): -![image](/mc/images/display_rgb_dmd.jpg) +![image](/docs/mc/images/display_rgb_dmd.jpg) Before we go into the details of all the various display components, let's start with an overview of how the MPF display architecture works. diff --git a/docs/mc/slides/index.md b/docs/mc/slides/index.md index 4c1f3412e0..b79b44be9b 100644 --- a/docs/mc/slides/index.md +++ b/docs/mc/slides/index.md @@ -21,7 +21,7 @@ what visual effect is used to transition from the current slide to the new slide. (Transitions are things like cross-fade, move in, push out, etc.) -![image](/mc/images/how_slides_work.png) +![image](/docs/mc/images/how_slides_work.png) ## Slide Priorities @@ -62,7 +62,7 @@ priorities of the slides in the stack and the priority of the current slide on one display has nothing to do with the active and current slides of another display. -![image](/mc/images/slides_with_multiple_displays.png) +![image](/docs/mc/images/slides_with_multiple_displays.png) * [Creating Slides](creating_slides.md) * [Showing Slides](showing_slides.md) diff --git a/docs/mc/slides/split_screen.md b/docs/mc/slides/split_screen.md index fb36dbd7c5..6fabe7f8f8 100644 --- a/docs/mc/slides/split_screen.md +++ b/docs/mc/slides/split_screen.md @@ -54,7 +54,7 @@ diagram shows the layout we will be creating, along with the lower left and upper right coordinates of each display widget based on a 1280 x 720 pixel main window. -![image](/mc/images/split_screen_layout.png) +![image](/docs/mc/images/split_screen_layout.png) To accomplish this in MPF, we will need to create a slide that will be shown in the main window display that will contain display widgets for @@ -134,7 +134,7 @@ The above config will display the `layout_4_mini` slide we just created as soon as the media controller is ready. Here is the result of the above config: -![image](/mc/images/split_screen_example.png) +![image](/docs/mc/images/split_screen_example.png) ## 3. Create additional slides and show them on one of the smaller displays @@ -253,7 +253,7 @@ slide_player: The above config results in the following output: -![image](/mc/images/split_screen_example_2.png) +![image](/docs/mc/images/split_screen_example_2.png) ## 4. Conclusion diff --git a/docs/mc/widgets/bitmap_fonts.md b/docs/mc/widgets/bitmap_fonts.md index 589ab2a3c0..e91e7e41ad 100644 --- a/docs/mc/widgets/bitmap_fonts.md +++ b/docs/mc/widgets/bitmap_fonts.md @@ -12,7 +12,7 @@ are several programs or online tools to create bitmap font descriptors. An example might look like this: -![image](/mc/images/bitmap_font_example.png) +![image](/docs/mc/images/bitmap_font_example.png) ## 2. Map Your Characters in a Descriptor File @@ -38,7 +38,7 @@ char id=32 x=0 y=550 width=40 height=55 xoffset=0 yoffset=0 xadvance=40 page=0 c ## 3. Put PNG File and Descriptor Into the bitmap_fonts Folder -![image](/mc/images/bitmap_font_file_structure.png) +![image](/docs/mc/images/bitmap_font_file_structure.png) Some things to note: diff --git a/docs/mc/widgets/dmd_fonts.md b/docs/mc/widgets/dmd_fonts.md index 8963a65157..67741961aa 100644 --- a/docs/mc/widgets/dmd_fonts.md +++ b/docs/mc/widgets/dmd_fonts.md @@ -27,7 +27,7 @@ slides: #! assert_text_on_top_slide MISSION ``` -![image](/mc/images/dmd_default.png) +![image](../images/dmd_default.png) Sure, it works, but it doesn't look good because the default font is a regular font that's made for a high-res display. @@ -55,7 +55,7 @@ slides: #! assert_text_on_top_slide MISSION ``` -![image](/mc/images/dmd_big.png) +![image](../images/dmd_big.png) ## style: med @@ -76,7 +76,7 @@ slides: #! assert_text_on_top_slide MISSION ``` -![image](/mc/images/dmd_med.png) +![image](../images/dmd_med.png) ## style: small @@ -102,4 +102,4 @@ slides: #! assert_text_on_top_slide MISSION ``` -![image](/mc/images/dmd_small.png) +![image](../images/dmd_small.png) diff --git a/docs/mc/widgets/easing.md b/docs/mc/widgets/easing.md index 9c1758fa9c..77a58dbee8 100644 --- a/docs/mc/widgets/easing.md +++ b/docs/mc/widgets/easing.md @@ -31,7 +31,7 @@ from 100% to 50% in 500ms, etc.) We can illustrate this with a graph, where time is the X axis, and the value is the Y axis, like this: -![image](/mc/images/easing_explained.png) +![image](/docs/mc/images/easing_explained.png) The image above shows the default formula with no easing applied. (This is technically the "linear" easing function.) The value of the @@ -42,7 +42,7 @@ But what if we wanted our animation to start slow and accelerate, then slow down again towards the end? For that, we could use a formula like this: -![image](/mc/images/anim_in_out_sine.png) +![image](/docs/mc/images/anim_in_out_sine.png) Notice that at the beginning (in the lower left corner), as you move right, the red line doesn't change too much. Then towards the middle, @@ -54,7 +54,7 @@ applied to animate text moving left and right. Don't worry about the function names. We'll cover those in a bit. -![image](/mc/images/easing.gif) +![image](/docs/mc/images/easing.gif) !!! note @@ -74,14 +74,14 @@ something to start slow, but then speed up without slowing down again. will have a gentle start and then it will shoot off and get faster and faster.) That function might look like this: -![image](/mc/images/anim_in_quart.png) +![image](/docs/mc/images/anim_in_quart.png) Conversely, if you have a widget coming in from off screen, you might want it to start out fast and then slow down as it approaches its final location. For that you could use what's essentially the opposite of the previous formula, like this: -![image](/mc/images/anim_out_quad.png) +![image](/docs/mc/images/anim_out_quad.png) The important thing to remember with these easing formulas is that the red line does NOT represent the path the moving objects take, rather, it @@ -103,7 +103,7 @@ can also include the size, scale, and/or the opacity (transparency). Here's an animated GIF showing the same five easing functions applied to each text widget's opacity property (cycling them between 1 and 0): -![image](/mc/images/easing_opacity.gif) +![image](/docs/mc/images/easing_opacity.gif) Refer to the [slide transition](../slides/transitions.md) and @@ -121,43 +121,43 @@ time and then accelerate to the end: `easing: in_back` -![image](/mc/images/anim_in_back.png) +![image](/docs/mc/images/anim_in_back.png) `easing: in_bounce` -![image](/mc/images/anim_in_bounce.png) +![image](/docs/mc/images/anim_in_bounce.png) `easing: in_circ` -![image](/mc/images/anim_in_circ.png) +![image](/docs/mc/images/anim_in_circ.png) `easing: in_cubic` -![image](/mc/images/anim_in_cubic.png) +![image](/docs/mc/images/anim_in_cubic.png) `easing: in_elastic` -![image](/mc/images/anim_in_elastic.png) +![image](/docs/mc/images/anim_in_elastic.png) `easing: in_expo` -![image](/mc/images/anim_in_expo.png) +![image](/docs/mc/images/anim_in_expo.png) `easing: in_quad` -![image](/mc/images/anim_in_quad.png) +![image](/docs/mc/images/anim_in_quad.png) `easing: in_quart` -![image](/mc/images/anim_in_quart.png) +![image](/docs/mc/images/anim_in_quart.png) `easing: in_quint` -![image](/mc/images/anim_in_quint.png) +![image](/docs/mc/images/anim_in_quint.png) `easing: in_sine` -![image](/mc/images/anim_in_sine.png) +![image](/docs/mc/images/anim_in_sine.png) ## Easing "end" functions @@ -166,43 +166,43 @@ meaning they start fast and then slow down towards the end: `easing: out_back` -![image](/mc/images/anim_out_back.png) +![image](/docs/mc/images/anim_out_back.png) `easing: out_bounce` -![image](/mc/images/anim_out_bounce.png) +![image](/docs/mc/images/anim_out_bounce.png) `easing: out_circ` -![image](/mc/images/anim_out_circ.png) +![image](/docs/mc/images/anim_out_circ.png) `easing: out_cubic` -![image](/mc/images/anim_out_cubic.png) +![image](/docs/mc/images/anim_out_cubic.png) `easing: out_elastic` -![image](/mc/images/anim_out_elastic.png) +![image](/docs/mc/images/anim_out_elastic.png) `easing: out_expo` -![image](/mc/images/anim_out_expo.png) +![image](/docs/mc/images/anim_out_expo.png) `easing: out_quad` -![image](/mc/images/anim_out_quad.png) +![image](/docs/mc/images/anim_out_quad.png) `easing: out_quart` -![image](/mc/images/anim_out_quart.png) +![image](/docs/mc/images/anim_out_quart.png) `easing: out_quint` -![image](/mc/images/anim_out_quint.png) +![image](/docs/mc/images/anim_out_quint.png) `easing: out_sine` -![image](/mc/images/anim_out_sine.png) +![image](/docs/mc/images/anim_out_sine.png) ## Easing both "start" and "end" functions @@ -212,43 +212,43 @@ then slow down again at the end. `easing: in_out_back` -![image](/mc/images/anim_in_out_back.png) +![image](/docs/mc/images/anim_in_out_back.png) `easing: in_out_bounce` -![image](/mc/images/anim_in_out_bounce.png) +![image](/docs/mc/images/anim_in_out_bounce.png) `easing: in_out_circ` -![image](/mc/images/anim_in_out_circ.png) +![image](/docs/mc/images/anim_in_out_circ.png) `easing: in_out_cubic` -![image](/mc/images/anim_in_out_cubic.png) +![image](/docs/mc/images/anim_in_out_cubic.png) `easing: in_out_elastic` -![image](/mc/images/anim_in_out_elastic.png) +![image](/docs/mc/images/anim_in_out_elastic.png) `easing: in_out_expo` -![image](/mc/images/anim_in_out_expo.png) +![image](/docs/mc/images/anim_in_out_expo.png) `easing: in_out_quad` -![image](/mc/images/anim_in_out_quad.png) +![image](/docs/mc/images/anim_in_out_quad.png) `easing: in_out_quart` -![image](/mc/images/anim_in_out_quart.png) +![image](/docs/mc/images/anim_in_out_quart.png) `easing: in_out_quint` -![image](/mc/images/anim_in_out_quint.png) +![image](/docs/mc/images/anim_in_out_quint.png) `easing: in_out_sine` -![image](/mc/images/anim_in_out_sine.png) +![image](/docs/mc/images/anim_in_out_sine.png) We'd like to give a shout out and thanks to the creators of the Kivy multimedia library (which is what the MPC MC uses) for [creating the diff --git a/docs/mc/widgets/easing_config.md b/docs/mc/widgets/easing_config.md index 3519a6f57d..97d12f9d96 100644 --- a/docs/mc/widgets/easing_config.md +++ b/docs/mc/widgets/easing_config.md @@ -9,7 +9,7 @@ the complete MPF machine config for them. First, here's the GIF where we set the easing for the x (horizontal position) property and move them left and right: -![image](/mc/images/easing.gif) +![image](../images/easing.gif) !!! note @@ -120,7 +120,7 @@ slide_player: And here's the example where we animate the opacity: -![image](/mc/images/easing_opacity.gif) +![image](../images/easing_opacity.gif) ``` mpf-mc-config # config_version=5 diff --git a/docs/mc/widgets/ellipse.md b/docs/mc/widgets/ellipse.md index e80ce3862d..0e0d69d024 100644 --- a/docs/mc/widgets/ellipse.md +++ b/docs/mc/widgets/ellipse.md @@ -54,7 +54,7 @@ slide_player: And the result: -![image](/mc/images/ellipse.png) +![image](../images/ellipse.png) ## Settings diff --git a/docs/mc/widgets/layers.md b/docs/mc/widgets/layers.md index 6936f289dd..98938a0291 100644 --- a/docs/mc/widgets/layers.md +++ b/docs/mc/widgets/layers.md @@ -57,7 +57,7 @@ slides: The result is like this. Note that widget3.1 is on top of widget3.2, which is on top of widget3.3: -![image](/mc/images/widget_layers_order.jpg) +![image](../images/widget_layers_order.jpg) In this example, all three widgets are 100% opaque, but if any of them had opacity of less than 100%, then you would see the lower level widget @@ -101,7 +101,7 @@ slides: And the results: -![image](/mc/images/widget_layers_z.jpg) +![image](../images/widget_layers_z.jpg) Note that *widget3.2* is on top since it's `z:` is 100, then *widget3.3* is next with `z: 2`, and finally *widget3.1* is on the diff --git a/docs/mc/widgets/line.md b/docs/mc/widgets/line.md index e4e38712be..92be1608ed 100644 --- a/docs/mc/widgets/line.md +++ b/docs/mc/widgets/line.md @@ -39,7 +39,7 @@ slide_player: And the results: -![image](/mc/images/line.png) +![image](../images/line.png) ## Settings diff --git a/docs/mc/widgets/opacity.md b/docs/mc/widgets/opacity.md index 3ac619c9fd..ab6be83fe9 100644 --- a/docs/mc/widgets/opacity.md +++ b/docs/mc/widgets/opacity.md @@ -15,7 +15,7 @@ Here's an example. (This example is from the [MC Demo](../../examples/mc_demo.md) which you can download and run to see it in action.) -![image](/mc/images/opacity_example.png) +![image](/docs/mc/images/opacity_example.png) ## Specifying opacity by opacity: setting diff --git a/docs/mc/widgets/points.md b/docs/mc/widgets/points.md index dec70202fb..a00927fbf8 100644 --- a/docs/mc/widgets/points.md +++ b/docs/mc/widgets/points.md @@ -27,7 +27,7 @@ slide_player: Which results in the following: -![image](/mc/images/points.png) +![image](/docs/mc/images/points.png) ## Settings diff --git a/docs/mc/widgets/positioning.md b/docs/mc/widgets/positioning.md index caf8021cf4..4e19a81b74 100644 --- a/docs/mc/widgets/positioning.md +++ b/docs/mc/widgets/positioning.md @@ -29,7 +29,7 @@ on slide (horizontal, then vertical). Here's a simple example that illustrates this: -![image](/mc/images/widget_positioning_basics.png) +![image](/docs/mc/images/widget_positioning_basics.png) By the way, in MPF, the actual "pixel size" of the display as MPF sees it is separate from actual pixels of the physical display. So you could @@ -62,14 +62,14 @@ anchor settings are applied to different widgets. The red bulls-eye target represents the point that's used by MPF to position that widget with each type of anchor settings. -![image](/mc/images/widget_anchors.png) +![image](/docs/mc/images/widget_anchors.png) ## 3. Combing anchors and widget positioning Now that you know how the coordinates and anchors work, let's look at some examples that combine these two concepts: -![image](/mc/images/widget_positioning_with_anchors_1.png) +![image](/docs/mc/images/widget_positioning_with_anchors_1.png) In the diagram above, you can see how the bulls-eye anchor target is the actual point of the widget that is positioned with each widget's `x:` @@ -104,7 +104,7 @@ of math to get your values set. Fortunately MPF can use relative positions for a widget's `x:` and `y:` values, as show here: -![image](/mc/images/widget_positioning_with_anchors_2.png) +![image](/docs/mc/images/widget_positioning_with_anchors_2.png) There are a lot of different options in this diagram, so let's go through them one-by-one. @@ -187,7 +187,7 @@ on a DMD), it still has two blank rows of pixels below every letter. This means that if you set the `anchor_y: bottom` on both your text and the circle, they will not actually be aligned: -![image](/mc/images/widget_bad_offset.png) +![image](/docs/mc/images/widget_bad_offset.png) What's even worst is that this font only has 1 extra row on top, so if you want to center-align it with another widget you won't get the @@ -224,7 +224,7 @@ Going back to the example from before, if we add `adjust_bottom: 2`, that will move the adjustment point 2 pixels towards the middle, meaning our bottom alignment now actually aligns: -![image](/mc/images/widget_good_offset.png) +![image](/docs/mc/images/widget_good_offset.png) Negative values have the effect of adding padding to widgets, which can also be nice as you're aligning and distributing things. @@ -252,7 +252,7 @@ MPF-MC to round fractional anchor positions in the specified direction. * `round_anchor_y: top` - Round the vertical pixel position up * `round_anchor_y: center` - Do not round the pixel position (default) -![image](/mc/images/widget_anchor_rounding.png) +![image](/docs/mc/images/widget_anchor_rounding.png) This setting is valid on `widgets` and `displays`. If you have a display and a widget both configured for rounding, the widget's setting will diff --git a/docs/mc/widgets/quad.md b/docs/mc/widgets/quad.md index ac0d61aed6..ebe25b3a6e 100644 --- a/docs/mc/widgets/quad.md +++ b/docs/mc/widgets/quad.md @@ -24,7 +24,7 @@ slide_player: Which results in the following: -![image](/mc/images/quad.png) +![image](/docs/mc/images/quad.png) ## Settings diff --git a/docs/mc/widgets/rectangle.md b/docs/mc/widgets/rectangle.md index 90c7c7f34c..d45bfb5ed3 100644 --- a/docs/mc/widgets/rectangle.md +++ b/docs/mc/widgets/rectangle.md @@ -41,7 +41,7 @@ slide_player: Which results in the following: -![image](/mc/images/rectangle.png) +![image](/docs/mc/images/rectangle.png) ## Settings diff --git a/docs/mechs/diverters/index.md b/docs/mechs/diverters/index.md index c69f1ba005..c59842bff4 100644 --- a/docs/mechs/diverters/index.md +++ b/docs/mechs/diverters/index.md @@ -12,9 +12,9 @@ Related Config File Sections: In MPF, a diverter (sometimes spelled "divertor") is anything that alters the path of the ball based on the state it's in, including: -![image](/mechs/images/diverter1.jpg) +![image](../images/diverter1.jpg) -![image](/mechs/images/diverter2.jpg) +![image](../images/diverter2.jpg) * A traditional diverter which is a metal flap at the end of a rod, typically used on ramps to "divert" the ball one way or the other. @@ -46,9 +46,9 @@ to them goes towards one place, and when they're active, a ball is In MPF, a diverter (sometimes spelled "divertor") is anything that alters the path of the ball based on the state it's in, including: -![image](/mechs/images/diverter1.jpg) +![image](../images/diverter1.jpg) -![image](/mechs/images/diverter2.jpg) +![image](../images/diverter2.jpg) * A traditional diverter which is a metal flap at the end of a rod, typically used on ramps to "divert" the ball one way or the other. diff --git a/docs/mechs/diverters/up_down_ramps.md b/docs/mechs/diverters/up_down_ramps.md index 2f49f31458..7ede9698af 100644 --- a/docs/mechs/diverters/up_down_ramps.md +++ b/docs/mechs/diverters/up_down_ramps.md @@ -14,7 +14,7 @@ typically act as a diverter and should be configured as such. ## Hardware -![image](/mechs/images/up-down-ramp.jpg) +![image](../images/up-down-ramp.jpg) Up-Down ramps either work with one coil or two coils. Single-coil ramps use the coil to move the ramp up or down temporarily Typically, they use diff --git a/docs/mechs/lights/flashers.md b/docs/mechs/lights/flashers.md index d4d4378050..0d3beeab5e 100644 --- a/docs/mechs/lights/flashers.md +++ b/docs/mechs/lights/flashers.md @@ -17,9 +17,9 @@ MPF includes support for flashers, which are essentially just really bright lights that are controlled via high-power driver transistors instead of low-power lighting circuitry. -![image](/mechs/images/flasher1.jpg) +![image](/docs/mechs/images/flasher1.jpg) -![image](/mechs/images/flasher2.jpg) +![image](/docs/mechs/images/flasher2.jpg) MPF's flasher devices are only used in older machines (WPC, Stern SAM, System 11) since modern LED-based machines typically use regular LED diff --git a/docs/mechs/lights/lights_versus_leds.md b/docs/mechs/lights/lights_versus_leds.md index 3024af6a46..5c1673716d 100644 --- a/docs/mechs/lights/lights_versus_leds.md +++ b/docs/mechs/lights/lights_versus_leds.md @@ -1,5 +1,5 @@ --- -title: "Lights" versus "LEDs" +title: Lights versus LEDs --- # "Lights" versus "LEDs" (Some LEDs are lights!) @@ -32,7 +32,7 @@ The following diagram shows the different types. An easy way to tell is if your lights or LEDs have mini bayonet or mini wedge bases, they're *Matrix Lights*, and everything else is *LEDs*: -![image](/mechs/images/lights_vs_leds.jpg) +![image](/docs/mechs/images/lights_vs_leds.jpg) Note that it's possible that you'll have both matrix lights and direct connected LEDs in the same machine. For example, maybe you're writing diff --git a/docs/mechs/magnets/index.md b/docs/mechs/magnets/index.md index 5422f90648..105f08709a 100644 --- a/docs/mechs/magnets/index.md +++ b/docs/mechs/magnets/index.md @@ -14,11 +14,11 @@ can use to grab and release balls. It also includes the ability to set timings to "fling" a ball by grabbing, releasing, then pulsing the magnet again. -![image](/mechs/images/magnet1.jpg) +![image](../images/magnet1.jpg) -![image](/mechs/images/magnet2.jpg) +![image](../images/magnet2.jpg) -![image](/mechs/images/magnet3.jpg) +![image](../images/magnet3.jpg) Video about magnets: diff --git a/docs/mechs/plungers/auto_manual.md b/docs/mechs/plungers/auto_manual.md index 20f077069f..1e60c3a12e 100644 --- a/docs/mechs/plungers/auto_manual.md +++ b/docs/mechs/plungers/auto_manual.md @@ -16,11 +16,11 @@ plunge option. Here's an example of this: -![image](/mechs/images/auto_manual_plunger.jpg) +![image](../images/auto_manual_plunger.jpg) -![image](/mechs/images/auto_launcher_side.jpg) +![image](../images/auto_launcher_side.jpg) -![image](/mechs/images/auto_launcher_bottom.jpg) +![image](../images/auto_launcher_bottom.jpg) If you have a purely mechanical plunger with no autolaunch option, follow the [/mechs/playfields/ball_tracking](mechanical_with_switch.md) guide diff --git a/docs/mechs/plungers/coil_fired.md b/docs/mechs/plungers/coil_fired.md index 45487be865..2c6d16e9e1 100644 --- a/docs/mechs/plungers/coil_fired.md +++ b/docs/mechs/plungers/coil_fired.md @@ -16,12 +16,12 @@ launch the ball into play. Sometimes these look more-or-less like traditional plunger lanes, except there's a solenoid instead of a spring-powered plunger, like this: -![image](/mechs/images/coil_fired_plunger.jpg) +![image](../images/coil_fired_plunger.jpg) Other times these are more like "catapult" devices with a coil attached to the arm to launch the ball into play: -![image](/mechs/images/catapult_plunger.jpg) +![image](../images/catapult_plunger.jpg) Note that if you have a coil-fired ball launcher that's combined with a spring plunger (giving the option for manual spring launches or diff --git a/docs/mechs/plungers/index.md b/docs/mechs/plungers/index.md index a9cf5f4ea7..b36d1390e3 100644 --- a/docs/mechs/plungers/index.md +++ b/docs/mechs/plungers/index.md @@ -34,7 +34,7 @@ waiting to be plunged. Here's an example of this from a Pin\*Bot machine: -![image](/mechs/images/plunger_with_switch.jpg) +![image](../images/plunger_with_switch.jpg) If you have this type of spring-powered plunger with a switch that's active when a ball is sitting in it ready to be plunged, follow the @@ -50,7 +50,7 @@ ball is sitting in the plunger lane. Here's an example of this from Gottlieb Big Shot: -![image](/mechs/images/plunger_no_switch.jpg) +![image](../images/plunger_no_switch.jpg) If you have this type of spring-powered plunger with **no** switch that's active when a ball is sitting in it ready to be plunged, follow @@ -69,7 +69,7 @@ Here are two examples of slightly different versions of these, the left from a Stern Star Trek Premium, and the right from a Gottlieb Brooks 'n Dunn machine: -![image](/mechs/images/auto_manual_plunger.jpg) +![image](../images/auto_manual_plunger.jpg) If you have this type of auto/manual combo plunger, follow the [guide](auto_manual.md) to configure it in @@ -84,13 +84,13 @@ There are a few different physical forms of this. Here's a typical example from Judge Dredd where a coil shaft with a plastic tip is pulsed to launch the ball directly: -![image](/mechs/images/coil_fired_plunger.jpg) +![image](../images/coil_fired_plunger.jpg) And here's an example from Williams Star Trek: The Next Generation which uses a catapult-style mechanism in order to launch the ball into play. -![image](/mechs/images/catapult_plunger.jpg) +![image](../images/catapult_plunger.jpg) Note that both of these options are "identical" as far as MPF is concerned. They both have switches which are active when a ball is able diff --git a/docs/mechs/plungers/mechanical_no_switch.md b/docs/mechs/plungers/mechanical_no_switch.md index 62d69a3cb2..d650e310e4 100644 --- a/docs/mechs/plungers/mechanical_no_switch.md +++ b/docs/mechs/plungers/mechanical_no_switch.md @@ -21,7 +21,7 @@ including many EM and early solid state machines.) Here's an example from a Gottlieb Big Shot -![image](/mechs/images/plunger_no_switch.jpg) +![image](../images/plunger_no_switch.jpg) ## 1. Configure your trough / ball drain diff --git a/docs/mechs/plungers/mechanical_with_switch.md b/docs/mechs/plungers/mechanical_with_switch.md index 3e40a5c5f4..fa5e4234c9 100644 --- a/docs/mechs/plungers/mechanical_with_switch.md +++ b/docs/mechs/plungers/mechanical_with_switch.md @@ -16,7 +16,7 @@ plunger with MPF. This guide is for use with a plunger lane that has a switch in the lane which is activated by a ball waiting to be plunged, like this: -![image](/mechs/images/plunger_with_switch.jpg) +![image](../images/plunger_with_switch.jpg) If you have a mechanical spring plunger but you do NOT have a switch there, then follow the [/mechs/playfields/ball_tracking](mechanical_no_switch.md) guide instead. diff --git a/docs/mechs/pop_bumpers/index.md b/docs/mechs/pop_bumpers/index.md index eec79f6940..8a96307094 100644 --- a/docs/mechs/pop_bumpers/index.md +++ b/docs/mechs/pop_bumpers/index.md @@ -17,9 +17,13 @@ Popbumpers are configured as ## Hardware -![Pop Bumper Data East/Sega/Williams 500-5227-00](/mechs/images/pop_bumper.jpg) +Pop Bumper Data East/Sega/Williams 500-5227-00 -![Pop Bumpers Installed in Playfield](/mechs/images/pop_bumpers_installed.jpg) +![image](../images/pop_bumper.jpg) + +Pop Bumpers Installed in Playfield + +![image](../images/pop_bumpers_installed.jpg) Pop bumpers are made of three elements relevant for MPF: diff --git a/docs/mechs/servos/index.md b/docs/mechs/servos/index.md index a471a48fdc..0bb8e44884 100644 --- a/docs/mechs/servos/index.md +++ b/docs/mechs/servos/index.md @@ -9,7 +9,7 @@ Related Config File Sections: * [servo_sequence](../../config/servos.md) -![image](/mechs/images/servos.jpg) +![image](../images/servos.jpg) A servo is device which can move to a certain position based on internal feedback. There is no need to add position switches and the servo will diff --git a/docs/mechs/slingshots.md b/docs/mechs/slingshots.md index ef1dfb5881..1138b620e7 100644 --- a/docs/mechs/slingshots.md +++ b/docs/mechs/slingshots.md @@ -15,9 +15,9 @@ in MPF. ## Hardware -![image](/mechs/images/slingshot_side.jpg) +![image](images/slingshot_side.jpg) -![image](/mechs/images/slingshot_front.jpg) +![image](images/slingshot_front.jpg) A sling shot usually consists of two [blade switches](switches/mechanical_switches.md) and one [coil](../config/coils.md). Those switches are wired in parallel because it does not diff --git a/docs/mechs/steppers.md b/docs/mechs/steppers.md index e89eabafad..4b1fc7ae5a 100644 --- a/docs/mechs/steppers.md +++ b/docs/mechs/steppers.md @@ -9,9 +9,9 @@ Related Config File Sections: * [steppers:](../config/steppers.md) -![image](/mechs/images/stepper_driver.jpg) +![image](images/stepper_driver.jpg) -![image](/mechs/images/stepper_with_switch.jpg) +![image](images/stepper_with_switch.jpg) Stepper motors offer digitally controlled precise movement of mechanisms. They require a separate driver board that interfaces with diff --git a/docs/mechs/switches/mechanical_switches.md b/docs/mechs/switches/mechanical_switches.md index 67ea5e0388..6a6d257408 100644 --- a/docs/mechs/switches/mechanical_switches.md +++ b/docs/mechs/switches/mechanical_switches.md @@ -25,7 +25,7 @@ There are two common types of mechanical switches: First, blade switches which are very cheap and reliable but cannot be used everywhere: -![image](/mechs/images/blade_target_switch.jpg) +![image](../images/blade_target_switch.jpg) Typically, those are use for [flipper buttons](../flippers/index.md) @@ -70,7 +70,7 @@ over switches. Those usually have three connectors: Usually, you connect `C` to ground and `NO` to your direct input (see below for switch matrices). -![image](/mechs/images/micro_switches_common_no_nc.jpg) +![image](../images/micro_switches_common_no_nc.jpg) Electronically and logically both switches work similarly. diff --git a/docs/mechs/switches/optos.md b/docs/mechs/switches/optos.md index bf682f9307..6c3b93f733 100644 --- a/docs/mechs/switches/optos.md +++ b/docs/mechs/switches/optos.md @@ -118,9 +118,9 @@ them. ### Williams/Bally Optos -![image](/mechs/images/williams_optos_front.jpg) +![image](/docs/mechs/images/williams_optos_front.jpg) -![image](/mechs/images/williams_optos_back.jpg) +![image](/docs/mechs/images/williams_optos_back.jpg) In most platforms with direct inputs you can directly connect a receiver to an input. You connect the collector to the input (`C`) and the @@ -160,7 +160,7 @@ Part numbers: Labels on Stern Spike optos looks different but they work similarly: -![image](/mechs/images/spike_optos_front.jpg) +![image](/docs/mechs/images/spike_optos_front.jpg) On the transmitter (left) connect `+5` to 5V and `G` to GND. A current limiting resistor is not required since it is embedded on the sender. @@ -175,7 +175,7 @@ Part numbers: ### Multimorphic Optos: -![image](/mechs/images/multimorphic_optos.jpg) +![image](/docs/mechs/images/multimorphic_optos.jpg) Multimorphic produces and sells optos with a JST connector. The transmitter contains a current limiting resistor for 12V (you only have diff --git a/docs/mechs/switches/rollover_switches.md b/docs/mechs/switches/rollover_switches.md index 3d867c362e..64adc3b2c5 100644 --- a/docs/mechs/switches/rollover_switches.md +++ b/docs/mechs/switches/rollover_switches.md @@ -14,7 +14,7 @@ they are often paired with a light (below an insert) which qualifies them as candidate for a shots in MPF. They are usually [mechanical micro switches](mechanical_switches.md). -![image](/mechs/images/rollover_micro_switch.jpg) +![image](../images/rollover_micro_switch.jpg) Typical part numbers: diff --git a/docs/mechs/switches/service_and_door_switches.md b/docs/mechs/switches/service_and_door_switches.md index 0d0f4ddbc9..f6f216598f 100644 --- a/docs/mechs/switches/service_and_door_switches.md +++ b/docs/mechs/switches/service_and_door_switches.md @@ -12,7 +12,7 @@ Related Config File Sections: Most pinball machines have service switches inside their service door. Additionally, there is usually a switch to detect if the door is open. -![image](/mechs/images/service_switches.jpg) +![image](../images/service_switches.jpg) You can configure those to control your [service mode](../../game_logic/service_mode.md). diff --git a/docs/mechs/targets/drop_targets/drop_target_bank.md b/docs/mechs/targets/drop_targets/drop_target_bank.md index fc809c972d..28dae8f7fc 100644 --- a/docs/mechs/targets/drop_targets/drop_target_bank.md +++ b/docs/mechs/targets/drop_targets/drop_target_bank.md @@ -15,7 +15,7 @@ The main reasons for doing this are to combine reset coils (since one coil typically resets an entire bank) and to get additional events posted when the entire bank is up, down or in a mixed state. -![image](/mechs/images/drop_target_bank.jpg) +![image](/docs/mechs/images/drop_target_bank.jpg) This is an example: diff --git a/docs/mechs/targets/stationary_targets.md b/docs/mechs/targets/stationary_targets.md index 01646c5ee1..fc1d67c94c 100644 --- a/docs/mechs/targets/stationary_targets.md +++ b/docs/mechs/targets/stationary_targets.md @@ -9,7 +9,7 @@ Related Config File Sections: * [switches:](../../config/switches.md) -![image](/mechs/images/blade_target_switch.jpg) +![image](../images/blade_target_switch.jpg) Mission Pinball Framework's (MPF) *stationary target* device represents a switch in a pinball machine. This might also be know as a stand-up diff --git a/docs/mechs/targets/vari_targets.md b/docs/mechs/targets/vari_targets.md index 1fbbad3475..e25731ccd5 100644 --- a/docs/mechs/targets/vari_targets.md +++ b/docs/mechs/targets/vari_targets.md @@ -17,18 +17,18 @@ hit the more points awarded. This is a vari-target in a Gottlieb Playball (1971): -![image](/mechs/images/vari_target_top.jpg) +![image](../images/vari_target_top.jpg) Technically, a vari-target has one switch per position and a reset coil to reset the target: -![image](/mechs/images/vari_target_disengaged.jpg) +![image](../images/vari_target_disengaged.jpg) It can reset the target at any position. Either directly after a hit or once it has moved till the end (or never). This is how a vari-target looks fully engaged: -![image](/mechs/images/vari_target_engaged.jpg) +![image](../images/vari_target_engaged.jpg) If you got an example config for a vari target [please contribute it](../../about/help.md). diff --git a/docs/mechs/troughs/classic_single_ball.md b/docs/mechs/troughs/classic_single_ball.md index 766ba43713..2782730450 100644 --- a/docs/mechs/troughs/classic_single_ball.md +++ b/docs/mechs/troughs/classic_single_ball.md @@ -17,12 +17,12 @@ electronic single ball machines of the early 1980s. Here's an example from a Gottlieb Big Shot (1974 EM): -![image](/mechs/images/classic_single_ball_trough_photo.jpg) +![image](../images/classic_single_ball_trough_photo.jpg) And here's a diagram which shows this a bit more clearly: (This is a side view) -![image](/mechs/images/classic_single_ball.png) +![image](../images/classic_single_ball.png) We assume that your machine has a shooter lane switch. If that is not the case see [/mechs/plungers/index](classic_single_ball_no_shooter_lane.md). diff --git a/docs/mechs/troughs/classic_single_ball_no_shooter_lane.md b/docs/mechs/troughs/classic_single_ball_no_shooter_lane.md index 59e74da0e4..901c0ea5c5 100644 --- a/docs/mechs/troughs/classic_single_ball_no_shooter_lane.md +++ b/docs/mechs/troughs/classic_single_ball_no_shooter_lane.md @@ -15,7 +15,7 @@ the 1950s through electronic single ball machines of the early 1980s. Here's an example from a Gottlieb Playball (1971 EM): -![image](/mechs/images/classic_single_ball_trough_without_shooter_lane_photo.png) +![image](../images/classic_single_ball_trough_without_shooter_lane_photo.png) ## 1. Add the drain switch diff --git a/docs/mechs/troughs/index.md b/docs/mechs/troughs/index.md index b733781771..cec8d11780 100644 --- a/docs/mechs/troughs/index.md +++ b/docs/mechs/troughs/index.md @@ -21,7 +21,7 @@ been used over the past 70 years, and (as far as we know), MPF supports all of them. So regardless of what's in your machine, we're talking about whatever is under here: -![image](/mechs/images/trough_drain.jpg) +![image](../images/trough_drain.jpg) Here are the options: @@ -80,7 +80,7 @@ rather than infrared opto boards. (Other than that, they're the same as the opto-based troughs.) Here's a photo of a modern trough with mechanical switches from a Stern Star Trek Premium machine: -![image](/mechs/images/modern_mechanical_trough_photo.jpg) +![image](../images/modern_mechanical_trough_photo.jpg) If you have a modern-style trough with mechanical switches instead of opto boards, then read the [guide](modern_mechanical.md) to continue. @@ -110,7 +110,7 @@ because each ball is sitting on a switch. Here's a photo of this type of trough system from a Pin\*Bot machine: -![image](/mechs/images/two_coil_multiple_switches_trough_photo.jpg) +![image](../images/two_coil_multiple_switches_trough_photo.jpg) If you have this kind of trough system, read the [guide](two_coil_multiple_switches.md) to @@ -136,7 +136,7 @@ full. Here's a photo from a Gottlieb System 3 machine (Brooks 'n Dunn) which shows what this type of system looks like: -![image](/mechs/images/two_coil_one_switch_trough_photo.jpg) +![image](../images/two_coil_one_switch_trough_photo.jpg) If your machine has a system similar to this, then read the [guide](two_coil_one_switch.md) to continue. @@ -151,7 +151,7 @@ way into the plunger lane in a single action. Here's an example from Gottlieb Big Shot: -![image](/mechs/images/classic_single_ball_trough_photo.jpg) +![image](../images/classic_single_ball_trough_photo.jpg) If you have a system like this, read the [guide](classic_single_ball.md) to continue. @@ -163,7 +163,7 @@ playfield. There is no shooter lane. This was used in early EM machines. Here's an example from Gottlieb Playball: -![image](/mechs/images/classic_single_ball_trough_without_shooter_lane_photo.png) +![image](../images/classic_single_ball_trough_without_shooter_lane_photo.png) If you have a system like this, read the [guide](classic_single_ball_no_shooter_lane.md) to continue. diff --git a/docs/mechs/troughs/two_coil_one_switch.md b/docs/mechs/troughs/two_coil_one_switch.md index 24b4d46673..6240e027cd 100644 --- a/docs/mechs/troughs/two_coil_one_switch.md +++ b/docs/mechs/troughs/two_coil_one_switch.md @@ -17,7 +17,7 @@ This guide is written for the types of devices that have only have one switch on the trough side, like this example of a Gottlieb System 3 machine (Brooks 'n Dunn): -![image](/mechs/images/two_coil_one_switch_trough_photo.jpg) +![image](../images/two_coil_one_switch_trough_photo.jpg) If your trough system has multiple switches in the trough (one for each ball), then use @@ -32,7 +32,7 @@ the last ball that goes into it sits on the switch. The following diagram shows a more clear view of the type of trough system this guide is for: (This is a side view) -![image](/mechs/images/two_coils_one_switch.png) +![image](../images/two_coils_one_switch.png) ## 1. Add the switches diff --git a/docs/start/media_controller.md b/docs/start/media_controller.md index 0e0491a120..345647819a 100644 --- a/docs/start/media_controller.md +++ b/docs/start/media_controller.md @@ -26,7 +26,7 @@ part that shows the graphics and plays the sounds. Here's a diagram that shows what each piece does: -![image](/mc/images/mpf_game_engine_mc.png) +![image](/docs/mc/images/mpf_game_engine_mc.png) More details about MPF's media controller architecture, as well as guides which show you how to run them on separate computers, or even to diff --git a/docs/tools/showcreator.md b/docs/tools/showcreator.md index bd24fa60fc..5c9cb03982 100644 --- a/docs/tools/showcreator.md +++ b/docs/tools/showcreator.md @@ -73,7 +73,7 @@ Mark, the maker of the [Nightmare before Christmas custom pinball machine](https://pinside.com/pinball/forum/topic/the-nightmare-before-christmas), created this awesome MPF Lightshow generator. -![image](/tools/images/showcreator.png) +![image](images/showcreator.png) The tool allows you to set a shape (i.e. a star in the example), choose a start and an end position and color. Based on that it will create a @@ -95,12 +95,12 @@ that shape anywhere you want over the playfield. Here we start with a gradient bar at the top of the playfield in a pink color. -![image](/tools/images/showcreator_start.png) +![image](images/showcreator_start.png) We want the final position to be here at the bottom, in a darker red shade. -![image](/tools/images/showcreator_end.png) +![image](images/showcreator_end.png) You can then adjust the length of the animation in milliseconds and hence the number of steps in the final show. In this example, the shape @@ -113,7 +113,7 @@ passes over. Lightshow playback speed can be adjusted in MPF. You're not restricted to just the included shapes. You can make your own shapes and drop them in the shapes folder. -![image](/tools/images/showcreator_shapes.png) +![image](images/showcreator_shapes.png) Once you get the hang of animating a single shape, you can go further by adding in more shapes. You can add a total of 256 shapes in animation