doc: showcases: fixed parameter names, factual info, and typos

Author: adamgeorge309

showcases/measurement/flow/omnetpp.ini

@@ -97,8 +97,8 @@ abstract = true
 *.client*.measurementLayer.measurementStarter[1].flowName = "BG"
 *.client*.measurementLayer.measurementStarter[1].packetFilter = expr(has(udp) && udp.srcPort == 1000)
 *.client*.measurementLayer.measurementStarter[*].measure = "elapsedTime or queueingTime"
-*.client*.measurementLayer.measurementRecorder[*].typename = ""
+*.client*.measurementLayer.measurementMaker[*].typename = ""
 
-*.server*.measurementLayer.measurementRecorder[0].flowName = "VID or BG"
-*.server*.measurementLayer.measurementRecorder[*].measure = "elapsedTime or queueingTime"
+*.server*.measurementLayer.measurementMaker[0].flowName = "VID or BG"
+*.server*.measurementLayer.measurementMaker[*].measure = "elapsedTime or queueingTime"
 *.server*.measurementLayer.measurementStarter[*].typename = ""

showcases/mobility/basic/doc/index.rst

@@ -95,8 +95,8 @@ Some of these mobility models are introduced by the following example simulation
 LinearMobility
 ~~~~~~~~~~~~~~
 
-The :ned:`LinearMobility` module describes linear motion with a constant speed or
-constant acceleration. As such, it has parameters for speed and starting angle.
+The :ned:`LinearMobility` module describes linear motion with a constant speed.
+As such, it has parameters for speed and starting heading.
 The model also has parameters for initial positioning (:par:`initialX`,
 :par:`initialY`, :par:`initialZ`), which, by default, are random
 values inside the constraint area.
@@ -108,8 +108,8 @@ The configuration in omnetpp.ini is the following:
    :start-at: *.host[*].mobility.typename = "LinearMobility"
    :end-at: speed
 
-We leave the angle parameter on its default value, which is
-a random value.
+We leave the :par:`initialMovementHeading` parameter on its default value,
+which is a random value.
 
 The following video shows the motion of the nodes:
 

showcases/mobility/combining/doc/index.rst

@@ -159,8 +159,8 @@ You can take a look at the ``Superpositioning1`` configuration in omnetpp.ini:
 
 The :par:`numElements` parameter defines the number of mobility submodules,
 which are contained in a submodule vector named :par:`element`.
-Therefore, instead of :par:`mobility.typeName = XY`, the mobility
-submodules can be referenced with :par:`mobility.element[0].typeName = XY`.
+Therefore, instead of :par:`mobility.typename = XY`, the mobility
+submodules can be referenced with :par:`mobility.element[0].typename = XY`.
 This is also visible if we take a look at the inside of ``host[0]``'s
 mobility submodule:
 

showcases/routing/manet/ManetProtocolsShowcase.ned

@@ -3,7 +3,6 @@ package inet.showcases.routing.manet;
 import inet.networklayer.configurator.ipv4.Ipv4NetworkConfigurator;
 import inet.node.inet.ManetRouter;
 import inet.physicallayer.wireless.ieee80211.packetlevel.Ieee80211RadioMedium;
-import inet.physicallayer.wireless.ieee80211.packetlevel.Ieee80211ScalarRadioMedium;
 import inet.visualizer.canvas.integrated.IntegratedMultiCanvasVisualizer;
 
 
@@ -111,7 +110,7 @@ network ManetprotocolsShowcaseB
         destination: ManetRouter {
             @display("p=292,80");
         }
-        radioMedium: Ieee80211ScalarRadioMedium {
+        radioMedium: Ieee80211RadioMedium {
             @display("p=38,28");
         }
         configurator: Ipv4NetworkConfigurator {

showcases/routing/manet/doc/index.rst

@@ -203,8 +203,8 @@ Configuration and Results
 This section contains the configuration and results for the three
 simulations, which demonstrate the MANET routing protocols ``AODV``,
 ``DSDV`` and ``GPSR``. The AODV and DSDV simulations use the
-``ManetRoutingProtocolsShowcaseA`` network, which features moving hosts.
-The GPSR simulation uses the ``ManetRoutingProtocolsShowcaseB`` network,
+``ManetprotocolsShowcaseB`` network, which features moving hosts.
+The GPSR simulation uses the ``ManetprotocolsShowcaseA`` network,
 featuring stationary hosts. The networks are defined in
 :download:`ManetProtocolsShowcase.ned <../ManetProtocolsShowcase.ned>`.
 Both networks contain hosts of the type :ned:`ManetRouter` (an extension of
@@ -241,7 +241,7 @@ AODV
 
 The example simulation featuring AODV is defined in the :ned:`Aodv`
 configuration in :download:`omnetpp.ini <../omnetpp.ini>`. This
-configuration uses the ``ManetProtocolShowcaseB`` network. The network
+configuration uses the ``ManetprotocolsShowcaseB`` network. The network
 looks like the following:
 
 .. figure:: media/networkA.png
@@ -329,12 +329,12 @@ leading to ``destination``. When the route is established in ``source``,
 it sends the ping request packet, which gets to the destination. The
 ping reply packet gets back to ``source`` on the reverse path.
 
-When source sends the next ping request packet, ``host6`` has already
+When source sends the next ping request packet, ``node6`` has already
 moved out of range of ``destination``. The ping packet gets to
-``host6``, but can't get to ``destination`` (``host6`` tries to transmit
-the packet a few times, but it doesn't get an ACK). So ``host6``
+``node6``, but can't get to ``destination`` (``node6`` tries to transmit
+the packet a few times, but it doesn't get an ACK). So ``node6``
 broadcasts an ``AodvRerr`` message, indicating that the link no longer
-works. When the RERR gets back to ``host1``, it initiates route discovery
+works. When the RERR gets back to ``node1``, it initiates route discovery
 by broadcasting an RREQ message. When a new route is discovered
 (``source``->``node1``->``destination``), the ping traffic can continue.
 
@@ -350,7 +350,7 @@ DSDV
 The example simulation featuring DSDV is defined in the :ned:`Dsdv`
 configuration in :download:`omnetpp.ini <../omnetpp.ini>`. Just like
 the AODV configuration, this one uses the
-``ManetRoutingProtocolsShowcaseB`` network. The mobility settings are
+``ManetprotocolsShowcaseB`` network. The mobility settings are
 also the same as in the AODV simulation. The ping app in ``source`` will
 send a ping request every second.
 

showcases/tsn/timesynchronization/clockdrift/doc/index.rst

@@ -145,7 +145,7 @@ simulation time. Also, we need to explicitly tell the relevant modules (here,
 the UDP apps and ``switch1``'s queue) to use the clock module in the host,
 otherwise, they would use the global simulation time by default.
 
-We set the :par:`nominalTickLenght` parameter of all oscillators to 10ns, which is a typical value for
+We set the :par:`nominalTickLength` parameter of all oscillators to 10ns, which is a typical value for
 real-world clocks. To be able to represent 1 PPM clock drift, we set fs simulation time accuracy (10ns / 10^6 = 10fs).
 
 Here are the drifts (time differences) over time:

showcases/tsn/trafficshaping/creditbasedshaper/doc/index.rst

@@ -64,7 +64,7 @@ To conveniently incorporate a credit-based shaper into a network interface, it
 can be added as a submodule to an :ned:`Ieee8021qTimeAwareShaper`. The
 :ned:`Ieee8021qTimeAwareShaper` module supports a configurable number of traffic
 classes, pre-existing queues for each class, and can be enabled for Ethernet
-interfaces by setting the :par:`enableEgressTrafficShaping` parameter in the
+interfaces by setting the :par:`hasEgressTrafficShaping` parameter in the
 network node to ``true``. To utilize a credit-based shaper, the
 ``transmissionSelectionAlgorithm`` submodule of the time-aware shaper can be
 overridden accordingly. As an example, here is a time-aware shaper module that
@@ -129,7 +129,7 @@ Within the client, our goal is to classify packets originating from the two
 packet sources into two traffic classes: `best effort` and
 `video`. To achieve this, we activate IEEE 802.1 stream
 identification and stream encoding functionalities by setting the
-:par:`hasOutgoingStreams` parameter in the switch to ``true``. We proceed by configuring the stream
+:par:`hasOutgoingStreams` parameter in the client to ``true``. We proceed by configuring the stream
 identifier module within the bridging layer; this module is responsible for
 associating outgoing packets with named streams based on their UDP destination
 ports. Following this, the stream encoder sets the Priority Code Point (PCP) number on the packets according to

showcases/tsn/trafficshaping/timeawareshaper/doc/index.rst

@@ -74,7 +74,7 @@ Visualizing Gate Schedules
 
 The configured gate schedules can be visualized with the :ned:`GateScheduleVisualizer` module. It displays a gate schedule in time, as a colored bar near the network node containing the gate, on the top-level canvas (by default, to the right). The horizontal axis of the bar is time, and the current time is indicated by a dashed vertical line in the center. The gate schedule is displayed as color-coded blocks on the bar. Green blocks signify the open, and red blocks the closed gate state. The blocks move to the right with simulation time, so that the current time is in the center, the past is to the left, and the future is to the right. Thus, the visualization shows if the gate is currently open or closed, and when it will change state in the future.
 
-The visualization can be enabled by setting the visualizer's :par:`displayGates` parameter to ``true``. By default, it displays all gates in the network, but this can be narrowed down with the
+The visualization can be enabled by setting the visualizer's :par:`displayGateSchedules` parameter to ``true``. By default, it displays all gates in the network, but this can be narrowed down with the
 :par:`gateFilter` parameter.
 
 For example, two gates in the same interface are visualized on the image below:

showcases/visualizer/canvas/mobility/doc/index.rst

@@ -20,7 +20,7 @@ About the Visualizer
 In INET, the mobility of nodes can be visualized by :ned:`MobilityVisualizer`
 module (included in the network as part of :ned:`IntegratedCanvasVisualizer`). By
 default, mobility visualization is enabled; it can be disabled by
-setting :par:`displayMovements` parameter to false.
+setting :par:`displayMobility` parameter to false.
 
 By default, all mobilities are considered for the visualization. This
 selection can be narrowed with the visualizer's :par:`moduleFilter`
@@ -37,9 +37,9 @@ The visualizer has several important features:
    movement's direction. The arrow's length is proportional to the
    node's speed.
 -  **Orientation Arc**: Node orientation is represented by an arc whose
-   size is specified by the :par:`orientationArcSize` parameter. This value
+   size is specified by the :par:`orientationPieSize` parameter. This value
    is the relative size of the arc compared to a full circle. The arc's
-   default value is 0.25, i.e. a quarter of a circle.
+   default value is 0.2, i.e. a fifth of a circle.
 
 These features are disabled by default; they can be enabled by setting
 the visualizer's :par:`displayMovementTrails`, :par:`displayVelocities` and

showcases/visualizer/canvas/packetdrop/doc/index.rst

@@ -31,7 +31,7 @@ are visualized. This selection can be narrowed with the :par:`nodeFilter`,
 (The :par:`packetFilter` can filter for packet properties, such as name, fields, chunks, protocol headers, etc.)
 Additionally, use the :par:`detailsFilter` parameter to filter for packet drop reasons.
 
-The :par:`packetFormat` parameter is a format string and specifies the text displayed with the packet drop animation.
+The :par:`labelFormat` parameter is a format string and specifies the text displayed with the packet drop animation.
 By default, the dropped packet's name is displayed.
 The format string can contain the following directives: