Total found:3007
Reply To: Hazard /Disable groups question for Cobra V7.x

That all makes sense, thanks!   It would be cool to have the ‘by position’ option later, glad it’s at least a reasonable idea 🙂   J

Reply To: Hazard /Disable groups question for Cobra V7.x

Hey NEC, the “Hazard” column values have to be set in the script window. You can also populate the “Hazard Default” column in the effects window. If an effect contains a default hazard value before it’s added to the show, the hazard value will automatically be added to the script. The “Hazard Default” column in the effects window isn’t linked to the “Hazard” column in the script to give you line-by-line control over each script row. For example, this allows you to have 3″ salutes on position A with a different Hazard value than 3″ salutes of the same part number on position B. If the hazard columns were linked, all 3″ salutes of the same part number would have the same hazard value. If you’re not taking advantage of default Hazard values for your effects, you may want to check that out.   There’s not currently a way to set a hazard default on a per- rack or per-position basis. It’s a neat idea tough and might be an enhancement we can make in the future.

Reply To: Bulk edit rack physical properties?

Hey NEC, no problem, “Physical Specifications” is a column that you can unhide in the effects window from the blue gear ⚙️ icon. To learn the syntax for the column, try setting the physical specifications for an item using the dialog, then compare the values you entered to the text that’s generated and added to the Physical Specifications column.

Reply To: Trouble creating Double Wing Slice Cake – RA143035

Hey Curtis B, if your cake can be represented by one of the standard Firing patterns for cake and slice rows, then yes, it can absolutely be converted. You mentioned create a cake from cakes, this caught my eye. Creating a cake by combining other cakes can give you bad results. I don’t recommend it and I can’t think of a reason it should be necessary.   It should always be possible arrange the individual shots for a cake on the timeline and then do ‘Combine as cake…’. If the cake combiner can’t match the firing pattern on the timeline to one of the standard firing patterns, it will fall back to the exact syntax. In most cases, the cake combiner should give you ideal VDL. In rare cases, you might be able to do better by handwriting the VDL.   To try and convert your cake to use a standard firing pattern, I would break it apart into single shots, then try recombining it. If the cake combiner can figure out how to represent the cake without the exact syntax, then the only option is to hand write the VDL.

Reply To: Degrees specifications (potential bug???)

Hey DrewFinale I’m not able to recreate the bug anymore… not sure how I created it in the first place but it isn’t wanting to happen again. It may have been a previous version and once I updated the bug disappeared. Thanks!

Reply To: Trouble creating Double Wing Slice Cake – RA143035

I think I caused some initial confusion as I posted by ‘inverted’ VDL before I saw you post (that’s what I get for posting before refreshing the page). You answer was clear.  The part I was missing was that you could build this type of mine using the ‘above’ VDL keyword instead of adding new nodes in the effect editor. Short of some tweaking, I don’t see a big reason to use the effect editor here (or in general).  Rarely so I need to change the details at that level.   I build most of my cakes by making individual effects and combining them into a cake. I don’t especially care the resulting syntax because I just break it apart when I want to change something.   The Glossary of VDL terms is great to have this year – thanks for finishing that up. I got excited when you showed me the work in progress at PGI.  Huge help!   -Brett

Reply To: Trouble creating Double Wing Slice Cake – RA143035

DrewFinale is there a way to turn the VDL I created into a “normal” VDL or due to the nature of the effect and having to create a cake effect from multiple cake effects makes it impossible to NOT use exact syntax?

Bulk edit rack physical properties?

Is there a way to see the physical properties for all racks in an effects file?  I have a lot of editing to do and it would be nice if I could see all of them in a table format to edit   J

Addressing algorithm

The “Addressing algorithm” is the procedure the computer follows to assign modules, pins, racks and tubes to the events of the show.  The basic procedure is a lot like what a human would do: Decide in what sort order you will assign addresses to effects. Take the first effect in that order, and assign it the lowest number module, pin, rack, and tube that satisfy all the constraints. After the assignment, look ahead to assign any same-time or same-chain effects to the same module and pin and the lowest number rack and tube that satisfy constraints. Repeat from step (2) until finished. Rearrange the tubes in the single-shot racks to avoid collisions between tubes with crossing angles. If you turn off step (5) rearrangement, the results of the algorithm are fully transparent and 100% determined by the sort order and the constraints specified in the addressing dialog, meaning that a human could follow these same steps to get the same result.  You can fall back on this truth if you ever question the results of the addressing algorithm: follow the same steps and see if you get the same result.   Sort order The sort order is a list of criteria, sorting first by criterion 1, then breaking ties by criterion 2, then breaking further ties by criterion 3, etc.  Sort criteria include attributes like Position Name, Size, and Part Number.  In fact it is easy to imagine assigning modules and pins sorted by those exact criteria, and many people do. Sort criteria can also include conditional terms, like “Size >= 50mm (If Single-Shot)”, which sorts single-shot items of size >= 50mm first; then other single-shot items; then non-single-shot items in their original order.  The purpose of conditional sort terms with phrases like “(If Single-Shot)” is to apply some criteria to some kinds of effects without affecting others.  For example, it may be important to assign racks and tubes to large (>= 50mm) single-shots before others if a launch position has a limited number of racks capable of holding the larger effects, which you wouldn’t want to fill with smaller effects until ensuring you have dealt with all the large effects. Sort criteria can also include derived terms like “Rack Number”, which prioritize effects that fit in the next rack according to the Rack Numbers.  The precise definitions and calculations of derived terms like Rack Number are often complicated.  If the meaning isn’t obvious or if you are trying to step through exactly what the computer is doing, you can refer to the list of terms and their definitions here: Special sort terms.   Constraints Unlike the list of sort order terms, constraints come from multiple places.  The addressing dialog provides lists of constraint fields applying to modules, slats, pins, and racks, and provides the constraint, “Max. e-matches per pin”.  The rack definition dialog for the “Create/edit rack” functions includes pre-wired pins, various size constraints, usable length of rack row constraints for Pyrolamas-like racks, and constraints related to angles.  Effects have a Type property that must be compatible with the rack structure (cake racks vs. single-shot racks, etc.).  Positions can have pre-wired rails.  Script rows can have Rack Type values that are required to match the Rack Type properties of the racks. Like sort terms, constraint fields applying to modules, slats, pins, and racks can refer to attributes like Position, Size and Part Number, or other more complicated conditional and derived terms like “Rack (If Single-Shot)” or “Chain-Or-Not” (see Special constraints). The important characteristic of constraints is that they combine in a principled manner.  The combination of constraint 1 and constraint 2 means simply that constraint 1 and constraint 2 must both be satisfied by any assignment of modules, pins, racks, and tubes.  Because of this characteristic, you can configure the addressing algorithm to take into account a staggeringly large and complex set of considerations while still being able to rely on the predictability and verifiability of the result.   Example sort order and constraints for single-shot racks with pre-wired pins Addressing for pre-wired pins on racks with angle range constraints requires a significant amount of sort order and constraint calculation which illustrates the complexity.   The specific terms are listed in Table 1 of Racks with pre-wired pins.  Figure 1 is an excerpt:   Figure 1 – Example sort order and constraints for pre-wired pins.   The “Tilt > 50° — Single-Shot” sort term guarantees that single-shots angled more than 50° get to allocate the tube holders on the ends of the rows that are the only holders capable of rotating to those extreme angles.  Similarly, the “Size >= 50mm — Single-Shot” sort term ensures large holder single-shot racks are allocated first to the large effects that need them.  The “One Single-Shot Rack” constraint restricts a module to zero or one single-shot rack but allows pins to be shared with other non-single-shot racks.  See Racks with pre-wired pins for the full explanation of the terms in this example.