e possible to change the component definition making possible to customize the number of outputs.Now Dispatch moves "true" values to A and "False" values to B
INPUT:
L (List to work on) -> 1, 2, 3, 4, 5, 6, 7, 8
D (Dispatch Pattern) -> True, False
OUTPUT:
A (List) -> 1, 3, 5, 7
B (List) -> 2, 4, 6, 8
Could it be possible/useful to modify it so it could dispatch items to several outputs, like:
INPUT:
L (List to work on) -> 1, 2, 3, 4, 5, 6, 7, 8, 9, 0
D (Dispatch Pattern) -> A, B, C
OUTPUT:
A (List) -> 1, 4, 7, 0
B (List) -> 2, 5, 8
C (List) -> 3, 6, 9
maybe I'm missing something and there's already a component with this function... I have been searching on the forum for half afternoon, but can't find anything about it!
Thank you!…
0.9.0076 or Rhino SR12 has this bug, where if cannot read/export internalized data from/to millipede components. But one step at a time, huh?
Good luck,
Gediminas…
work. If you have been looking for an opportunity to get into a new part of the software or just want to get updated on the latest developments in a 90-minute presentation, then these webinars are for you. Starting this Thursday at 12:30 EST, the workshops will begin by covering basic Ladybug capabilities and will provide a survey of the latest community resources. Each Thursday, there will be another presentation covering progressively advanced topics. In total there will be 5 workshops, each of which you can register for by clicking below:
1 - Ladybug Climate Analysis - August 25th, 12:30 PM EST2 - Ladybug Facade + Shade Design - September 1st, 12:30 PM EST3 - Honeybee Energy, HVAC + Indoor Comfort Modeling - September 8th, 12:30 PM EST4 - Honeybee Daylight + Electric Light - September 15th, 12:30 PM EST5 - Honeybee THERM + WINDOW - September 22nd, 12:30 PM EST
Notably, workshops 2, 3, 4 and 5 will feature substantial coverage of capabilities that do not currently have tutorial videos. This includes new view analysis and tips and tricks for radiation studies in webinar 2, newly-released HVAC capabilities for webinar 3, electric lighting capabilities with webinar 4, and all of webinar 5 will be brand-new hot-off-the-press development! Hope that you can attend!…
it works is as follows:
The GH_Document has a list of objects that have scheduled a solution (or rather, it maintains a list of callback delegates those objects have registered).
It also contains a TimeSpan field, which remembers the shortest schedule.
If the ScheduleSolution method is called during a solution, the timer won't be started until the solution finishes. So the schedule doesn't control how often the solutions will occur, it controls the delay between solutions.
Let's imagine the following scenario (with insanely scaled up time spans):
At noon exactly, a new solution starts. It doesn't matter what triggered it.
While the solution is still running at 12:01, a component (A) schedules a new solution 15 minutes later. This component registers a callback delegate along with the schedule.
While the solution is still running at 12:02, another component (B) schedules a solution with a 5 minute delay. Since 5 minutes is less than 15 minutes, the document forgets about the 15 minute schedule and instead switches to a 5 minute schedule. (B) does not register a callback.
While the solution is still running at 12:03, a third component (C) schedules a solution with a 10 minute delay. 10 minutes is further into the future than 5 minutes, so the document does not accept this new schedule. (C) does however register a callback.
At 12:05, the solution finishes. The SolutionEnd event is raised, viewports and canvasses are redrawn.
Also at 12:05, the document starts a timer that will fire an event 5 minutes from now, at 12:10.
Nothing happens in this interval, and at 12:10 the schedule timer fires.
The document notices it has a list of two callbacks (registered to A and C respectively), so it invokes them. This allows (A) and (C) to perform some sort of preparation. The most common action is to expire the component that gets the callback, so it'll get included in the imminent solution.
Once the document has invoked all schedule callbacks, it starts a new solution.
Note that (A) and (C) got called back way earlier than they requested. They scheduled solutions for 15 and 10 minutes respectively, but instead got the call only 5 minutes in. They can either play ball and accept the new schedule, or they can choose to not expire themselves and instead schedule a new solution for the future.
If at point 7 instead of nothing happening, a new solution was triggered by some other event (user dragging a slider or changing a wire), all the callbacks are still handled, but now even earlier than they expected.
-----
You can always schedule a solution, which is what makes this solution more flexible than other approaches. It doesn't matter that a solution is already running. It doesn't matter that the schedule comes from another thread*.
On the other hand, schedules are annoying because the time you request is not necessarily the time you get.
Also, if you have 50 components that all want to schedule, you must pick a delay big enough so that they all manage to register their callbacks before the new solution starts. This may be tricky.
* I'm actually not 100% sure about the threadsafety, it could be that there's bugs under rare conditions.…
Added by David Rutten at 7:00am on February 11, 2015
nd router's external IP (分享器), not your computer's IP (it should look like 192.168.0.xxx).
Here's a quick tutorial to find your "real" IP: https://www.youtube.com/watch?v=g6Eyj8pjrNU…