Write a boolean expression for finding if the bit 3 (counting from 0) of a given integer is 1 or 0.
Check third bit
Binary representation :


Class that takes a ShutIt object and defines what a ShutIt module must
implement to be registered.
|
|
__init__(self,
module_id,
run_order,
description='
' ,
maintainer='
' ,
depends=None,
conflicts=None,
delivery_methods=[ ] )
Constructor. |
source code
|
|
|
|
get_config(self,
shutit)
Gets all config items necessary for this module to be built |
source code
|
|
|
|
|
|
|
remove(self,
shutit)
Remove the module, which should ensure the module has been deleted
from the system. |
source code
|
|
|
|
start(self,
shutit)
Run when module should be installed (is_installed() or configured to
build is true) Run after repository work. |
source code
|
|
|
|
|
|
|
|
|
|
build(self,
shutit)
Runs the build part of the module, which should ensure the module has
been set up. |
source code
|
|
|
|
|
|
|
finalize(self,
shutit)
Finalize the module, ie do things that need doing after final module
has been run and before we exit, eg updatedb. |
source code
|
|
|
Inherited from object :
__delattr__ ,
__format__ ,
__getattribute__ ,
__hash__ ,
__new__ ,
__reduce__ ,
__reduce_ex__ ,
__repr__ ,
__setattr__ ,
__sizeof__ ,
__str__ ,
__subclasshook__
|


RESEARCH INTERESTS I am a population biologist using mathematics to investigate how ecological and genetic factors influence the evolutionary process, and vice versa. My primary interests are evolutionary rescue, the effects of genetic backgrounds and linkage, and metabolic scaling theory. I am currently getting acquainted with the pop-gen inference game. For more info, please see publications.


What is Fleddit?
If Flicker and Reddit had a baby there would be Fleddit!
Here at Fleedit, we take the best of both worlds. We take Flickr and Reddit to create make your own creations in under 5 minutes!Want to make your friends laugh?
Well now you can! With 3 easy steps!


--- layout: page title: Minions of Steel tags: [] status: publish type: page published: true meta: _edit_last: "1" _wp_page_template: default ---
This is an independent RTS (with some FPS elements mixed in) game project which I contributed some coding work on (porting from Ogre 1.2 to 1.4, level/scene loading, input handling, collision detection, camera controls, etc). It is built on the Ogre3D game engine and uses a number of other components such as OIS for input, CEGUI for UI support, tinyxml for XML parsing, et al.
website


Hi there! I'm Ken Hoff. I work at GetStream.io.


This document describes the changes to LiquidFun present in each release. Releases are listed in reverse chronological order, with the most recent release at the top of page and the oldest release at the bottom.
Each release comprises the following sections:
- "Overview", which contains a high level description of the release.
- "New Features", which describes new functionality added in the release.
- "API Modifications", which details the set of API changes that could affect existing users' code.
- "Other Changes", which lists all other changes present in the release.
View the entire set of changes in a release of LiquidFun by doing one of the following:
1.1.0
Overview
The 1.1.0 release of LiquidFun adds support for new platforms, speeds-up the simulation, and documents the particle simulation algorithm with a fun, visual presentation. Some highlights:
- iOS support.
- JavaScript support via Emscripten.
- Improved Java support via more SWIG bindings.
- An Inside LiquidFun presentation explaining the particle simulation algorithm.
- ARM optimizations using NEON.
- Stability and collision improvements to the particle simulation.
- More ways to inspect particle contacts.
- A LiquidFun logo to use in your splash screens and documentation, if you like.
The API Modifications are minimal in this release, but please review them carefully before upgrading your project.
LiquidFun now supports Mac, Windows, Linux, Android, iOS, and browsers. Note that LiquidFun code is portable C++98, so you should be able to compile it for other platforms too.
Your program can use LiquidFun if it is written in C++, Java, or JavaScript.
LiquidFun 1.1.0 is based on Box2D revision 280, the 2.3.0 release of Box2D.
New Features
- Translated LiquidFun into JavaScript using Emscripten. Please see Box2D/lfjs for the JavaScript bindings and a JavaScript version of the Testbed.
- Added iOS XCode projects for the Testbed application and EyeCandy demo.
- Added b2ParticleSystem::SplitParticleGroup, which finds disjoint blobs of particles, and puts each into its own b2ParticleGroup.
- Added several accessor functions that use only int32s, float32s, and void pointers. These accessors are wrapped in the LIQUIDFUN_EXTERNAL_LANGUAGE_API preprocessor define. They enable binding with other languages–for example, via SWIG.
- Particle indices can be represented with 16-bits instead of 32-bits. This is a nice optimization if you know you will have less than 32k particles per simulation.
- b2ParticleSimulation::UpdateContacts has been rewritten to take advantage of NEON SIMD. The original implementation remains, for reference, and for platforms that do not support NEON SIMD. The NEON SIMD version requires 16-bit particle indices.
API Modifications
- b2ParticleContact's members are now accessed via Get and Set functions.
- b2ParticleSystemDef now has members for strictContactCheck, density, gravityScale, radius, and maxCount. You can still set these values after b2ParticleSystem creation, however, for example via b2ParticleSystem::SetDensity.
Other Changes
- Added b2ParticleSystem::GetAllParticleFlags, b2ParticleSystem::GetAllGroupFlags, and b2ParticleGroup::GetAllParticleFlags, which OR-together all the flags in a particle system or group.
- Expose the contact weight buffer. The weight represents how closely two particles overlap.
- Expose particle pairs and triads for reading. These arrays indicate which particles are interacting.
- Added b2ParticleGroup::GetLinearVelocityFromWorldPoint, which returns the average velocity of a particle group with respect to a position. The position is used to calculate the angular velocity of the group.
- Added b2World::CalculateReasonableParticleIterations to give a good estimate of the number of particle iterations you should pass into b2World::Step.
1.0.0
Overview
The 1.0.0 release of LiquidFun introduces a number of new features to the API described below. Some of the highlights are:
- Multiple particle systems.
- New particle behaviors: barrier, static-pressure, and repulsive.
- Particle lifetimes.
- Detection of stuck particles.
- The ability to apply forces and impulses to particles.
- Java support via SWIG.
- A host of new demos: inside the existing Testbed application, and gorgeous new "EyeCandy" demo for Android.
Users of 0.9.0 should carefully read through the API Modifications section to understand what they need to change to get their existing applications to work with the latest release of LiquidFun.
New Features
- Added option to substep particle simulation independently of
b2World
.
- Added barrier particles which can be used to prevent particle tunneling due to large particle velocities or simulation steps.
- Added static pressure particles to reduce compression of fluids.
- Added repulsive particles to separate particle groups from each other.
- Added support for multiple independent particle systems.
- Added option to create particles in an existing particle group.
- Added option to detect stuck particles.
- Added option to pause particle simulations. Paused simluations don't consume cycles in b2World::Step.
- Added option to enable a more strict check for Particle/Body interactions in cases where complex world geometry may cause false positive contacts.
- Added option to call a contact listener or filter on particle / fixture or particle / particle interactions.
- Added the ability to apply forces and impulses to particles.
- Added "EyeCandy" sample to demonstrate different particle rendering methods on Android.
- Added "Sparky", "Sandbox" and "Soup Stirrer" tests to the Testbed example to demonstrate particle and rigid body interaction.
- Added "Ramp", "Pointy", and "AntiPointy" tests to the Testbed example to illustrate the difference with strict contact checking.
- Added "Maxwell" test to the Testbed to demonstrate the direct modification of particle velocities.
- Added "Fracker" test to demonstrate particle viscous fluids and particle destruction callbacks.
- Added "Multiple Systems" test to the Testbed to demonstrate multiple particle systems.
- Added Java Native Interface support via SWIG. It covers a subset of the API.
- Added the ability to pass a list of shapes to be passed in for particle-group creation.
API Modifications
b2Draw::e_particleBit
flag now enables/disables b2World::DrawDebugData()
drawing the particle system.
To render the particle system using b2World::DrawDebugData()
, the b2Draw::e_particleBit
flag must be set on the b2Draw
object passed to b2World::SetDebugDraw()
. It is possible to set flags on b2Draw
objects using b2Draw::SetFlags()
.
Release 0.9.0 unconditionally called b2Draw::DrawParticles()
from b2World::DrawDebugData()
.
Building LiquidFun on Linux, using cmake -G"Unix Makefiles"
, now places output files in a build type sub-directory.
For example, the output executable of the Testbed example is now written to Box2D/Testbed/Release/Testbed when building using the Release configuration.
- Multiple independent particle systems can now exist, each with its own physical coefficients. Previously, only one particle system existed, and it always existed. Use b2World::CreateParticleSystem to create particle systems, and b2World::DestroyParticleSystem to destroy them.
- b2DestructionListener::SayGoodbye, b2QueryCallback::ReportParticle, and b2RayCastCallback::ReportParticle each now takes a b2ParticleSystem pointer as its first parameter. This change is necessary since multiple particle systems can now exist.
- The particle system API has moved from b2World to b2ParticleSystem. For example, b2ParticleSystem::DestroyParticlesInShape replaces b2World::DestroyParticlesInShape. You can use b2World::CreateParticleSystem or b2World::GetParticleSystemList() to acquire references to b2ParticleSystem.
- Removed "Particle" from many of the functions in the particle system API. The word is redundant now that the API is under b2ParticleSystem. The API now has the following naming convention:
- Renamed
b2ParticleFlag
b2DestructionListener
to b2DestructionListenerParticle
to be consistent with other particle flag names.
- Better particle-behavior stability.
Other Changes
- Integrated Box2D 2.3.0 release from Box2D revision 280.
- Reduced the size of particles in Testbed particle tests to be consistent with the size of rigid bodies.
- Improved damping force to prevent particle explosions.
- Fixed
b2Timer
bug that occurs when the usec component wraps.
- Added
b2Stat
to calculate min/max/mean of a set of samples, and integrated this functionality into Testbed to measure performance.
- Fixed memory leaks of large blocks allocated by b2BlockAllocator.
- Fixed incorrect stack-capacity calculation in b2VoronoiDiagram.
- Added operators to
b2ParticleColor
.
- Improved parameter and option selection in Testbed with the fullscreen UI.
- Cleaned up statistics display in Testbed.
- Fixed depth-buffer allocation when creating an empty particle group.
- Added build step to unit-test execution scripts.
- Added generation of code coverage report for unit-tests.
- Added a script to clean up temporary cmake files.
- Increased warning level and enabled conversion of warnings to errors.
- Added unit-test for b2IsValid().
- Added
b2World::QueryShapeAABB()
convenience function to query the world for objects in the AABB which encloses a shape.
- Inlined some simple b2ParticleSystem and b2ParticleGroup functions.
- Allowed particle systems to be culled from b2World::QueryAABB and b2World::RayCast.
- Added callbacks so an application can override b2Alloc() and b2Free() without modifying the library.
- Added valgrind support to unit-test runner on Linux / OSX.
- Added cygwin wrapper script for build.bat and build_android.bat on Windows.
- Added option to archive build artifacts from build scripts.
- Changed Android C++ runtime library to gnustl_static.
0.9.0
Overview
The initial release of LiquidFun is available for download from the 0.9.0 release release page.
New Features
- Particle system added to Box2D.
- Example applications ported to Android.
API Modifications
- No changes to the Box2D 2.3.0 pre-release API.
Other Changes
- Integrated Box2D 2.3.0 pre-release from Box2D revision 255.
- Unit-tests implemented for the particle system.
- Particle system tests added to the Testbed example application.
- Build-system support for Android.
- Moved documentation to Markdown/HTML.


As a result of the attack not just on Kweku Smoke alone but also on his manager, Kweku Smoke’s got injured on his neck and on his arm.
SEE ALSO: Shatta Wale threatens to beat up Kweku Smoke and burn his car for accusing him of stealing his song
Again, Kweku Smoke’s car has been destroyed with the windows and door glasses broken into pieces by Shatta Wale and his thugs. Shatta Wale used cement to smash his car
Kweku Smoke explains it was a peace meeting organized for him and Shatta Wale who promised to sign him to quash their difference and recent fight on social media.
But Kweku Smoke and his team got the shock of their lives when Shatta Wale and his team descended heavily on them and ‘disciplined’ them with no mercy.
Watch the video below
SEE ALSO: Addi Self ‘slaps’ Kweku Smoke for accusing Shatta Wale of stealing his song [Video]
Shatta Wale after Kweku Smoke accused him of stealing his song threatened to beat him and burn his car if he does not submit to him.
But Kweku Smoke refused to let go and explained how Shatta Wale promised to jump on the song when he heard and now claiming ownership.


LATEST
Wonder Women
2015
|
action, fantasy
|
Rating: 8 / 10
LATEST
Bohemian Rhapsody
2018
|
mystery, adventure
|
Rating: 8 / 10
LATEST
Django Unchained
2012
|
action, adventure
|
Rating: 7.8 / 10
LATEST
Mad Max: Fury Road
2015
|
action, adventure
|
Rating: 7.5 / 10
LATEST
Joker
2019
|
crime, thriller
|
Rating: 8.7 / 10


--- layout: page title: "Who Am I ?" sub-title: Karim El-Husseiny description: CO-Founder of GitHelp header-img: "img/whoiam.jpg" circular-img: "/img/mypic.jpg" ---
My name is Karim El-Husseiny from Cairo, Egypt. I am an entrepreneur who passionate about Web, Education and Efficiency. I love to write well-tested clean code which follows best practice and achieves highest performance. I specialise in Ruby and Javascript development (Ruby on Rails, Sinatra & AngularJS). Also I do like to design responsive UIs using modern CSS frameworks, and very interested in acronyms like TDD, OOD and DevOps.


If you´ve forgotten your password, enter your email address and we´ll send you an email telling you how to recover it.


Although Inishmore is the largest of the three Aran Islands, you can easily explore the entire island via bike.
Bike rentals are easy and cheap at Burke's Bicycle Hire. Burke can give you directions on how to get anywhere on the island.
Biking across Inishmore is a great way to really see all that the island has to offer.
Make sure you stop to take in the views along the ride!
Bike across the island to Dun Aonghasa, an old fort that sits on the edge of a cliff that is 60m high.
The fort does not have any rails or barriers so you can go right up to the edge of the cliff. It can be pretty scary on a windy day so be careful!
The lack of rails allows you to sit on the edge of the cliff and dangle your feet off the edge.
Dun Aonghasa has spectacular views and is a highlight of the island.
The fort also has an interesting history that can be learned about at the visitor center.
Come shop in the Aran Sweater Market and get your own authentic Aran sweater from one of the Aran Islands!
The store is huge and has a large variety of patterns, colors and price options.


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object | +--net.sf.saxon.trans.Mode
A Mode is a collection of rules; the selection of a rule to apply to a given element is determined by a Pattern.
| Field Summary | |
static int |
ALL_MODES
|
static int |
DEFAULT_MODE
|
| Constructor Summary | |
Mode()
Default constructor - creates a Mode containing no rules |
|
Mode(Mode omniMode)
Construct a new Mode, copying the contents of an existing Mode |
| Method Summary | |
void |
addRule(Pattern p,
java.lang.Object obj,
int precedence,
double priority)
Add a rule to the Mode. |
int |
getList(int fingerprint,
int type)
Determine which list to use for a given pattern (we must also search the generic list) |
java.lang.String |
getModeName()
Get the name of this mode (for diagnostic output). |
java.lang.Object |
getNextMatchRule(NodeInfo node,
java.lang.Object currentHandler,
Controller controller)
Get the rule corresponding to a given Node, by finding the next-best Pattern match after the specified object. |
java.lang.Object |
getRule(NodeInfo node,
Controller controller)
Get the rule corresponding to a given Node, by finding the best Pattern match. |
java.lang.Object |
getRule(NodeInfo node,
int min,
int max,
Controller controller)
Get the rule corresponding to a given Node, by finding the best Pattern match, subject to a minimum and maximum precedence. |
void |
setModeName(java.lang.String name)
Set the name of this mode (for diagnostic output). |
| Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Field Detail |
public static final int DEFAULT_MODE
public static final int ALL_MODES
| Constructor Detail |
public Mode()
public Mode(Mode omniMode)
omniMode
- the existing mode. May be null, in which case it is not copied| Method Detail |
public void setModeName(java.lang.String name)
public java.lang.String getModeName()
public void addRule(Pattern p, java.lang.Object obj, int precedence, double priority)
p
- a Patternobj
- the Object to return from getRule() when the supplied node matches this Patternprecedence
- the import precedence of the rulepriority
- the explicit or implicit priority of the rulepublic int getList(int fingerprint, int type)
public java.lang.Object getRule(NodeInfo node, Controller controller) throws javax.xml.transform.TransformerException
node
- the NodeInfo referring to the node to be matched
javax.xml.transform.TransformerException
public java.lang.Object getRule(NodeInfo node, int min, int max, Controller controller) throws XPathException
node
- the NodeInfo referring to the node to be matched
XPathException
public java.lang.Object getNextMatchRule(NodeInfo node, java.lang.Object currentHandler, Controller controller) throws javax.xml.transform.TransformerException
node
- the NodeInfo referring to the node to be matched
javax.xml.transform.TransformerException
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


Torque 2D – Particle Engine
Hierarchy
The Torque 2D (T2D) particle-engine is essentially split-up into two components. These are the “effect” (t2dParticleEffect) and the “emitter” (t2dParticleEmitter). An emitter is an object that actual emits particles in a configurable manner. An unlimited quantity of emitters can be created within an effect. An effect is essentially a container of emitters. Emitters cannot ‘see’ each other and therefore cannot alter each others properties. An effect can alter emitters’ properties by scaling them as a group.
As a practical example, let’s assume we want to create a fire-effect. We want the effect to have three components: smoke, flames and sparks. The good thing is that the effect allows you to create these three separate components and keep them all together, handling them as a single object but still allowing individual emitters to be configured. We can go ahead and create three emitters, each of which generate a component of the fire-effect: smoke, flames and sparks.
If we want to tweak an aspect of the smoke, we can go into the effect and look at the smoke-emitter we created and tweak its configuration. What if we want to increase the particle-sizes for all emitters in the effect, not just a single one; how do we do this? It’s actually really easy! We can do this because almost every configurable parameter in an emitter is duplicated in the container effect. How does this help us? Quite simply, the effect parameters scale all emitter parameters contained within it. This means that if we set the particle-size to x2, all particles in all the emitters become twice the size. This is a means to make effect-wide changes instantly.
As a note: not all parameters in the effect scale the emitters. The effect can directly control other emission properties if the respective emitters allow this. See below for more details.
The hierarchy for the fire-effect described above is shown below:-
particle-engine hierarchy
Fields
An effect or an emitter can be controlled via its fields. These fields are split-up into two groups.
The first group contains fields that simply contain values that are on/off, or have one or two values for things such as size etc. These values cannot be defined to change over time although they can be changed in script dynamically. These fields do things such as setting an emitter into “single-particle” mode or forcing the emitter to “track rotation” etc.
The second group, and the more powerful, contains fields which are called graph-fields. A graph-field is one which allows its values to be defined to vary over time, automatically in real-time. This is done by using a method called key-framing (a term used in animation). Each graph allows you to add keys to it. Each key is comprised of a time and a value. Entering multiple keys at various times/values will configure the field to change its output value over a period of time.
This is illustrated below:
graph-field visualisation
As you can see, the above graph-field has 4 keys defined. Assuming the time is in seconds, we can see that the field's value will change from 0 to 50 over a period of 1 second. If this field controlled the particle-size, then the particles would rapidly grow as it aged towards 1 second.
The particle-engine automatically linearly interpolates between the values. When the particle aged beyond 1 second, it would maintain its previous key-value, which in this case is 50; visualizing this, it would be a horizontal line on the above graph extending right from the fourth key.
It is important to note that key-times always progress in forward-time. That means that all key-times must be ahead of the previous one and no two keys can contain the same time although they can contain any valid value and repeat that value in multiple keys.
Timelines
Each graph-field is comprised of keys which are specified against a time-line, but what is this timeline? The answer depends on whether you’re discussing the effect or the emitter. The quick answer is that timelines come in two varieties. The first timeline is associated with the age of the effect (playing time) and the second timeline is associated with particle-age. These two timelines differ slightly in their definition of time though. Effect-age is specified in absolute-time (in seconds) since the effect started playing whereas particle-age is specified in normalized-time (see below for more discussion on this).
Before I discuss any more details, you should try to remember that the graph-fields are all suffixed in such a way as to describe what type of timeline they refer to. These are:-
|
Graph-Field Type Suffix |
Timeline Description |
Used In |
|
xxx_Scale |
Effect-Age Timeline (Emitter Value-Scaling) |
Effect Only |
|
xxx_Base |
Effect-Age Timeline (Base-Value) |
Emitter Only |
|
xxx_Var |
Effect-Age Timeline (Variation-Value) |
Emitter Only |
|
xxx_Life |
Particle-Age Timeline (Value-Scaling Over-life) |
Emitter Only |
Okay, so that all sounds quite complicated but in fact, it’s rather simple. From now on, we’ll use the same colouring as above to indicate a field in the effect or emitter. As an example and using the above graph, assume it is a graph-field in the effect and assume the value is a particle-scaling factor for all particles. What we would have defined then is the following:-
Scale when effect has been playing for 0.0 seconds is 0.
Scale when effect has been playing for 0.5 seconds is 5
Scale when effect has been playing for 0.9 seconds is 20
Scale when effect has been playing for 1.0 seconds is 50
This is pretty simple indeed and very powerful. Again, note that the key-times here are related to the time from when you start the effect playing and is absolute-time. If you restart the effect, the time is also reset and therefore the values picked from the graph change. As mentioned above; if the effect time goes beyond the defined keys in any graph-field then the value will stay at the last defined key, in this case 50.
Let us now discuss the emitter. The emitters are a little more complex because they contain graph-fields for both types of timelines but are easily identified by the prefix as described above.
Emitters contain “_life” fields which work on a different time-line than the one described above as the time is not absolute time but is normalized-time. What this means is that 0 is the start of particle-life, 0.5 is halfway through the particle-life and 1 is equal to the end of the particle-life. You cannot use time outside of the range 0 to 1. This may seem a little strange but the lifetime of particles can be configured separately and using normalized-time means that changing the absolute particle lifetime wouldn’t result in having to change all the key-times. A major advantage!
Again, using the above graph as an example, assume it is a graph-field in the emitter and assume the value is an absolute particle-size. What we would have defined then is the following:-
Size when particle starts (0.0) would be 0
Size when particle is halfway through its lifetime (0.5) would be 5
Size when particle is 9/10ths through its lifetime (0.9) would be 20
Size when particle dies (1.0) would be 50
Note that the above doesn’t describe how long the particle lives, just its size over its lifetime. All these fields are easy to identify: they are suffixed with “_life” as described above.
Graph-Field Types
As described above, there are four types of graph-fields, one of which is exclusive to the effect. Let’s start focusing on a real field within the particle-engine as an example of how these different field-types work. For this example, we’ll use the “speed” field which has all four types of graph-fields, three in the emitter and one in the effect. These are:
“speed_base” (effect-age timeline) in the Emitter.
“speed_var” (effect-age timeline) in the Emitter.
“speed_life” (particle-age timeline) in the Emitter.
“speed_scale” (effect-age timeline) in the Effect.
As indicated above, the first three types of fields for speed are all in the emitter. These are “base”, “var” and “life”. Let’s examine each of these in turn.
“_base” is a field which is used as a base-value. In this case, it would define the base-speed for a particle in world-units/sec. This value (as indicated above) is an effect-age timeline so this field defines the base-speed for particles (as they are emitted) as the effect ages. Note that this does not change the base-speed of particles after they have been emitted, only as they are emitted (created).
“_var” is a field which is used as a variation on the “base” value. In this case, it would define a variance around the base-speed. The term variance means that a random value of the range specified would be used. This value is not directly added to the base but sits ‘around’ the base. A variance of 10 would produce a value in the range -5 to +5. This value (as indicated above) is an effect-age timeline so this field defines the variation on the base-speed for particles (as they are emitted) as the effect ages. Note that this does not change the base-speed of particles after they have been emitted, only as they are emitted (created).
“_life” is a field which is used to scale the resultant value of “base” + “variation” in realtime, during the lifetime of the particle. In this case, it would scale the speed. This value (as indicated above) is a particle-age timeline so this field defines the speed-scaling for particles as the particles age. Again note that this does change the size of particles after they have been emitted. Zero on the timeline here indicates the time when the particle is emitted (created) and one being its death.
“_scale” is a field which only exists in the effect and is used to scale the “base” + “var” used when particles are created. Note that this affects all emitters in the effect! This value (as indicated above) is an effect-age timeline so this field defines the scaling for speed for particles (as they are emitted) as the effect ages. Again note that this affects speed values for all emitters in the effect. Note that this does not change the base-speed of particles after they have been emitted, only as they are emitted (created).
So as you can see, there are two areas that these fields apply to. The first is the value used when the particle is emitted (created) and the second being the scaling applied during the lifetime of the particle. We’ll continue to discuss the “_scale” field in the effect but I will emphasize that it is only typically used for performing effect-wide scaling. Most effects would be created without using these fields. They can be exceptionally handy when you want to use a base effect and want different scaled versions or perhaps you want to render it in a different resolution camera-view and you need to scale the effect up/down. Either way, it isn’t typically used when creating particle-effects from scratch.
So choosing a value when a particle is emitted uses “_base”, “_var” and “_scale” and because these fields are all related, they all use the same timeline which is the effect's age. Scaling a value during a particle's lifetime uses “_life” and uses the particle's age.
The formula for calculating the value used when a particle is emitted (created) is as follows:
Value = (Base ~ Variation) * Scale.
Assuming that at the current effects-age, the base is 10, the variation is 6 and the scale is 2, we would calculate the value as:
(10 + (-3 to +3)) * 2 which ranges from (10-3)*2 to (10+3)*2 = 14 to 26.
Here’s an example (excluding “_life”) of particles being emitted:
As we can see here, as the effect ages to 5 seconds old, the value (let’s assume in this case its speed) increases. Not only does it increase but there is a range of increasing values marked by the light-blue band. This band is created because of the variation field which adds a level of randomness to the value.
Taking the value at time 5.0, the value range is calculated as:
20 + variance of 5 (-2.5 to +2.5) = 17.5 to 22.5
This range is then scaled by 2 to give a range of 35 to 45.
Now when doing this, you’re not interested in the math so much as the way the effect looks so here’s the way to use the fields. Set the “_base” value to the mid-point that you want the value to be. If you want a variance (randomness to the base), use the “_var” field. Quite often, you’ll not even use the “_scale” field as this is in the effect and applies to all emitters (see note above).
What is “_life”?
Okay, so we understand that our “bread and butter” fields are just “_base” and “_var” and maybe “_scale” in the effect (for more advanced work) but what is “_life”? “_life” is an extremely important graph-field that differs from the others.  This is where the “_life” field comes in. As discussed before, the timeline for these fields is based upon particle-age and ranges from 0 to 1.
The “_life” fields is really simple to understand as it simply scales the value over the particles-life, identical to the “_scale” field with the difference being that the “_scale” field is in the effect and globally scales all emitter fields and also uses the effects-age, rather than the particles’. “_life” changes only the single emitter value it’s in.
Functionality
Okay, now that we know that in an emitter we’ve got “_base” and “_var” to choose an emission-time value and “_life” to change the value over the particles-life, as well as the ability to go to the effect and scale the value for all emitters, let’s move onto describing what the fields do, irrespective of how you can define keys.
Here are the graph-fields within the emitter…
|
Graph-Field |
Field-Types in Emitter |
Description |
|
particlelife |
base / var |
How long the particle lives in seconds. This defines the time-time that “_life” works against. |
|
quantity |
base / var |
Quantity of particles emitted each second. This value should be kept as small as possible to reduce the performance overhead of the particle-effect. It is typically more efficient to produce ‘bigger’ particles than it is to produce more particles when trying to “fatten-up” the effect. |
|
sizex |
base / var / life |
X component of size (If “fixedaspect” (See below) is used then this controls Y component as well). All sizes are in world-units. |
|
sizey |
base / var / life |
Y component of size (If “fixedaspect” (See below) is used then this is ignored). |
|
speed |
base / var / life |
Speed here scales the particles velocity. A speed of one therefore produces no change. It is very important to understand that speed alone doesn’t produce any movement; the particle must have an initial velocity for speed to be useful. Initial velocity comes from “emissionforce” and “fixedforce” (see below). |
|
spin |
base / var / life |
Spin is simply rotation and is specified in degree/sec. |
|
fixedforce |
base / var |
Controls the magnitude of a fixed, constant force (angle specified elsewhere) applied to the particles. This can be used to simulate gravity or wind effects. |
|
randommotion |
base / var / life |
Controls the magnitude of random motion applied to particles. The magnitude is a variance in world-units. The random motion is omni-directional and is added to the particles position after its velocity calculation meaning that it doesn’t change the particles actual velocity so if it is reduced, the particles velocity stays the same. |
|
emissionforce |
base / var |
Controls the particles initial velocity when emitted. This can be changed with “speed”. |
|
emissionangle |
base / var |
Controls the base-angle that the particles will be emitted at (in degrees). |
|
emissionarc |
base / var |
Controls the arc around the chosen “emissionangle” (in degrees). |
|
red |
life |
Controls the red-channel for the particle-colour. If the particle texture is white, this controls how much red is applied to the particle. |
|
green |
life |
Controls the green-channel for the particle-colour. If the particle texture is white, this controls how much green is applied to the particle. |
|
blue |
life |
Controls the blue-channel for the particle-colour. If the particle texture is white, this controls how much blue is applied to the particle. |
|
visibility |
life |
Controls the alpha-channel for the particle-colour. This essentially controls how transparent the particle is and scales the particle-texture itself. A value of 0 makes the particle completely transparent whereas a value of 1 makes the particle opaque. Note that if the particle-texture already has an alpha-channel and is already transparent, then a value of 1 will make its transparency the same as the original texture. Essentially, the alpha value here is multiplied by any alpha-channel in the texture. |
Coloured-regions only used to separate field-groups
That’s it! After all that discussion, we’ve only got a handful of actual fields but each allows very precise control over how the values change over time. Also note that there are additional fields in the emitter that are not graph-fields but set other options. Things such as setting an “imageMap” or turning “fixed-aspect” on or off. These will be detailed later.
Well that’s the emitter, so what about the effect itself. Don’t forget that “scale” fields will scale all emitters in the effect. Anyway, here’s the list of fields…
|
Graph-Field |
Field-Types in Effect |
Description |
|
particlelife |
scale |
See Emitter for description. |
|
quantity |
scale |
See Emitter for description. |
|
sizex |
scale |
See Emitter for description. |
|
sizey |
scale |
See Emitter for description. |
|
speed |
scale |
See Emitter for description. |
|
spin |
scale |
See Emitter for description. |
|
fixedforce |
scale |
See Emitter for description. |
|
randommotion |
scale |
See Emitter for description. |
|
visibility |
scale |
See Emitter for description. |
|
emissionforce |
base / var |
See Emitter for description. |
|
emissionangle |
base / var |
See Emitter for description. |
|
emissionarc |
base / var |
See Emitter for description. |
The “odd” ones here are the “emissionXXX” fields. These don’t scale all the emitters, they do something else that can be very useful. There is an option in the emitter (“effectemission” – see below) that tells the emitter to ignore its own “emissionXXX” fields and use the ones in the effect. This means that individual emitters can choose to either have their own unique emission properties or use the parent-effect emission properties. An example of this being used would be if you have several emitters that all emit in the same way but a couple of them need to do something specific. This allows you to change all the common emissions at the effect-level but customize individual ones per emitter. The default is to use the effects emission so you’ll want to turn this off if you need to configure the emitter so that it has its own emission controls (see below).
Using Graphs
Now that we’ve seen a complete breakdown of what graphs are we can begin to look at the methods involved to modify their content. Note that this applies equally to effects as it does individual emitters as both objects contain these graph-fields and use the same methods to modify their content. Anyway, here’s a list of the functions available to modify a graph:
|
Script Function (Ref. Doc) |
Description |
|
selectGraph() |
Before you can begin to edit any graph-field, you must select it. If you select a graph-field, it will stay selected for the effect/emitter until another is selected. When you have selected a graph-field, all the following functions (see below) work on it. This is convienient and removes the need to specify the field in all the functions below. |
|
addDataKey() |
Adds a data-key to the graph. A data-key is comprised of a time and value combination. If a key at the same time already exists, it is overwritten with the new key. |
|
removeDataKey() |
Removes a data-key from the graph. Note that you cannot remove the data-key at time-zero! Note that data-keys are referenced by their key-index, not time or value. |
|
setDataKeyValue() |
Changes the value of an existing data-key. |
|
clearDataKeys() |
Removes all data-keys, leaving a data-key at time-zero with the graph-fields default value. |
|
setTimeRepeat() |
This option allows you to change the time-scaling for retrieving values from the graph. If data-keys are defined up to 10 seconds and the time-repeat is set to x2 then the final key will be reached in 5 seconds scene-time. The reason this function is called “repeat” rather than “scale” is because it is primarily used on “life” fields. Setting “x2” on these fields effectively repeats the fields twice during the lifetime of a particle whereas non “life” fields don-repeat. If a particle had its red-channel set to ramp from 0 to 1 during its life and “x4” was set for repeat, the particle would ramp from 0 to 1, 4 times during its life. |
|
setValueScale() |
This options sets a scale for all values retrieved from the graph. This is a convenient way to scale all the values coming from a graph without the need to change existing key values. |
|
getDataKey() |
Retrieves a data-key time/value combination. |
|
getDataKeyCount() |
Retrieves a count of data-keys. This can be used to enumerate the list of data-keys in conbination with “getDataKey()” above. |
|
getMinValue() |
Each graph-field sets bounds on the minimum value that can be used in any key. This is fixed by the system to a valid value. You can retrieve the minimum value using this function. |
|
getMaxValue() |
Each graph-field sets bounds on the maximum value that can be used in any key. This is fixed by the system to a valid value. You can retrieve the maximum value using this function. |
|
getMinTime() |
Each graph-field sets bounds on the minimum time that can be used in any key. This is fixed by the system to a valid value. You can retrieve the minimum time using this function. |
|
getMaxValue() |
Each graph-field sets bounds on the maximum time that can be used in any key. This is fixed by the system to a valid value. You can retrieve the maximum time using this function. |
|
getGraphValue() |
This function allows you to retrieve a calculated value from the graph at a specified time along the graph. You should specify a time within the range of “getMinTime()” and “getMaxTime()” (see above). This isn’t used by the particle-system but can be useful for debugging purposes or other general use. |
|
getTimeRepeat() |
Retrieves the time-repeat setting (see “setTimeRepeat()” above) |
|
GetValueScale() |
Retrieves the value-scale setting (see “setValueScale()” above) |
Grunt Work…
I can hear you say, “That’s great but how to I actually use these methods to manipulate keys in script?” No problem, let’s work through a few examples of doing just that.
Let’s assume we have the “fire effect” (described earlier) and that we want to create four keys at times, “0.0”, “0.5”, “0.9” and “1.0” in the “speed_life” graph-field of the “sparks” emitter. That sound like it’s going to be quite complicated but it actually isn’t so let’s just show the whole thing and then go through it piece by piece:
|
// Create a blank effect. %effect = new t2dParticleEffect() { scenegraph = mySceneGraph; };
// Load our fire-effect from disk. %effect.loadEffect( “fire.eff” );
// Find the “sparks” Emitter. %emitter = %effect.findEmitterObject( “sparks” );
// Select the “speed_life” graph-field. %emitter.selectGraph( “speed_life” ); // Clear any existing Keys. %emitter.clearDataKeys(); // Add our keys. %emitter.addDataKey( 0.0, 0 ); %emitter.addDataKey( 0.5, 5 ); %emitter.addDataKey( 0.9, 20 ); %emitter.addDataKey( 1.0, 50 );
|
The first two commands are pretty simple; we create a blank particle-effect and then load-up our pre-baked “fire” effect. Next we use the “findEmitterObject()” to get hold of the emitter we’re interested in, in this case the “sparks” emitter. Note that we could’ve selected the emitter by its index (if it didn’t have a name) using “getEmitterObject()” but this can change if the emitter order changes so it’s always preferable to access emitters by name. The emitters in this example effect are “smoke” (index#0), “flames” (index#1) and “sparks” (index#2) so we could’ve easily used:
|
… // Get the “sparks” Emitter by index. %emitter = %effect.getEmitterObject( 2 ); …
|
Anyway, let’s move onto the interesting part of this example which is actually selecting and changing a graph-field. We start this process by ‘selecting’ a graph-field using “selectGraph()” This may seem a little strange but it actually saves lots of work! By selecting a particular graph-field, you’re telling T2D that when you use a command that affects graph-fields in this emitter, it applies to the one you selected. T2D will use this graph-field until you change it so you only need to select it once. This saves you from having to specify which graph-field you are configuring in each command.
With the graph-field selected, we act a little cautiously by clearing any existing keys in the graph-field. What this actually does needs a little explaining though. The first thing to explain is that T2D ensures that all graph-fields are always valid. To do this, T2D enforces the rule that there must always be a key at time “0.0” and that all values for keys must be within the allowed range for the graph-field in question.
With that knowledge, it should be obvious that when you use “clearDataKeys()”, T2D does indeed clear any data-keys in the graph-field but it always automatically adds a data-key at time “0.0” that contains the default value for the graph-field in question (as defined in the reference documentation).
The good thing here is that you don’t have to constantly check if a data-key already exists at the time you want to add a key. T2D will simply overwrite the key if it exists, so if we were to use the following code…
|
// Add our keys. %emitter.addDataKey( 0.8, 0 ); %emitter.addDataKey( 0.8, 1 ); %emitter.addDataKey( 0.8, 2 ); %emitter.addDataKey( 0.8, 3 ); %emitter.addDataKey( 0.8, 4 ); %emitter.addDataKey( 0.8, 5 );
|
… which repeatedly adds a key at time “0.8”, it would result in the value “5” defined at time “0.8”. This simple feature means that you can just add a data-key to time “0.0”, knowing it already exists.
Anyway, back to our example; now that we’ve ‘cleared’ the graph-field, we can proceed to add four keys to it with:
|
// Add our keys. %emitter.addDataKey( 0.0, 0 ); %emitter.addDataKey( 0.5, 5 ); %emitter.addDataKey( 0.9, 20 ); %emitter.addDataKey( 1.0, 50 );
|
Well that was too easy so let’s manipulate these keys a little so we can see how it’s done. What we want to do now is remove the final key at time “1.0” and change the value at time “0.9” to “30”. We do this by extending the original code with:
|
// Remove the final key. %emitter.removeDataKey( 3 ); // Change the key at time “0.9”. %emitter.setDataKeyValue( 2, 30 );
|
As you can see, we use the “removeDataKey()” method but what is that curious value of “3”? It’s actually the key-index, identical to the indexes that can be used for addressing emitters. The keys we’ve got are “0.0” (index#0), “0.5” (index#1), “0.9” (index#2) and “1.0” (index#3) so we want to remove index#3. This may seem a little strange but you can use the methods “getDataKey()” and “getDataKeyCount()” to step through the keys for any graph-field.
Now that we’ve removed the final key, we want to simply set the key at time “0.9”. In this case, we used the method “setDataKeyValue()” to directly change the value of a key. Again, we’re using the key-index notation to address a key.
Let’s elaborate a little on the use of a key-index as it may seem a little complicated. In the above example, we use the method “setDataKeyValue()” but we could’ve equally specified the change using the time “0.9” like so:
|
// Change the key at time “0.9”. %emitter.addDataKey( 0.9, 30 );
|
This would’ve made much more sense as we know that adding a key, where a key already exists, just overwrites that key and we also knew the time we wanted to change, but what if we didn’t know the time and we wanted to go through all the keys and set them to a specific range of values?
Let’s do just that:
|
// Get Key-Count. %keyCount = emitter.getKeyCount(); // Step through all keys. for ( %n = 0; %n < %keyCount(); %n++ ) { // Get ‘old’ Key using its index. %oldKey = %emitter.getDataKey( %n );
// Change Key to some arbitrary value. %emitter.setDataKeyValue( %n, %n*10 );
// Get ‘new’ Key using its index. %newKey = %emitter.getDataKey( %n );
// Dump to Console. echo( “Key-change from“ SPC %oldKey SPC “to” SPC %newKey ); }
|
As you can see, we start by getting the count for the number of keys in our currently selected graph-field. We can then step through the keys and use “setDataKeyValue()” to change each. In the example we use “getDataKey()” to retrieve the key both before and after we change the value. We can then dump the details of the key-value changes to the console.
You don’t always have to enumerate the list to find key-indices though; T2D returns you the index to a key when you add it like so:
|
// Add our keys. %keyTime10 = %emitter.addDataKey( 10.0, 0 ); %keyTime20 = %emitter.addDataKey( 20.0, 5 ); %keyTime30 = %emitter.addDataKey( 30.0, 20 ); %keyTime40 = %emitter.addDataKey( 40.0, 50 ); // Dump to Console. echo( %keyTime10 SPC %keyTime20 SPC %keyTime30 SPC %keyTime40 ); // Outputs... “0 1 2 3”
|
Note that the key-indices are time-ordered. It’s also interesting to note that you don’t have to add keys in any specific timewise order either, so let’s do the above but in reverse order:
|
// Add our keys. %keyTime40 = %emitter.addDataKey( 40.0, 50 ); %keyTime30 = %emitter.addDataKey( 30.0, 20 ); %keyTime20 = %emitter.addDataKey( 20.0, 5 ); %keyTime10 = %emitter.addDataKey( 10.0, 0 ); // Dump to Console. echo( %keyTime10 SPC %keyTime20 SPC %keyTime30 SPC %keyTime40 ); // Still Outputs... “0 1 2 3”
|
You should note that you can change all effect/emitter fields whilst the effect is playing, there are no restrictions.  Well that pretty much covers most of the basic things you’ll want to do with graph-fields. There is, of course, much more functionality but we’ll let you discover that for yourself.
Enough Graphs Already!
Now that we’ve discussed the graph-fields, we just need to discuss the other options available to the emitters. These are generally simple options to control emission or provide supplementary parameters to the graph-fields above. These are:
|
Emitter Option |
Script Function (Ref. Doc) |
Description |
|
Name |
setEmitterName() |
Sets the emitters name. This is one method of retrieving the emitter from the effect in addition to retrieving via the emitters index. (See “findEmitterObject()” in ref. doc). Note that is it not neccesary for the emitters to have names, they are a convienience only. |
|
Type |
setEmitterType() |
There are four emitter types which control the region at which particles are created. Note that currently the area, which the types are based upon, uses the “effects” size e.g. “t2dParticleEffect::setSize()”. These types are:- “Point” – Point at the effects center. “LineX” – Line defined across effects X-axis. Y position is effects center. “LineY” – Line defined across effects Y-axis. X position is effects center. “Area” – Whole area of effects size. |
|
Visible |
setVisible() |
Controls whether the emitter is showing particles. NOTE:- Unlike other T2D objects, making an emitter invisible, destroys any existing particles and stops the emitter from creating any more. |
|
Orientation |
setParticleOrientation() |
There are three orientation types which control the orientation of particles when they are created and/or during their lifetime. Each option has further parameters which can be setting using other calls, detailed below. These orientation types are:- “Aligned” – Particles have their “up” direction aligned to the initial particle direction. Other options are “alignangle” and “keepaligned”. “Fixed” – Particles are aligned to a fixed angle. The fixed angle is specified using “fixedangle”. “Random” – Particles are aligned to a random angle. This random angle is specified using “randomangle” and “randomarc”. |
|
alignangle |
setAlignAngleOffset() |
This option is used when the “orientation” mode is set to “aligned”. It allows a fixed-angle offset to be added to the alignment function. Because the align-mode orientates the particles such that the initial “up” direction is facing the direction of particle travel and that the particle-texture used may be orientated in a different direction, you may wish to rotate the particle by a fixed-offset. |
|
keepaligned |
setAlignKeepAligned() |
This option is used when the “orientation” mode is set to “aligned”. It forces the particle to stay aligned to its current direction during its lifetime. This will override any other settings such as “spin”. Adding random-motion can cause the direction to change, this will keep the particle aligned to that new direction. In “aligned” mode, with this option off, the alignment applied when the particle is created. |
|
fixedangle |
setFixedAngleOffset() |
This option is used when the “orientation” mode is set to “fixed”. It indicates an angle for initially orientating the particle. Unless “spin” is used, the particle will stay orientated in this direction. |
|
randomangle |
setRandomAngleOffset() |
This option is used when the “orientation” mode is set to “random”. It indicates a fixed angle which the “randomarc” will be based-upon. |
|
randomarc |
setRandomArc() |
This option is used when the “orientation” mode is set to “random”. It indicates a random arc-range around the “randomangle”. This works identically to the idea of “base” and “var” with “randomangle” being the “base” and “randomarc” being the “var”. |
|
imagemap |
setImageMap() |
This specifies the imagemap/frame used for the emitter particles. This will disable the “animationname” option. |
|
animationname |
setAnimationName() |
This specifies the animation used for the emitter particles. This will disable the “imagemap” option. |
|
fixedaspect |
setFixedAspect() |
This option controls how the graph-fields “sizex” and “sizey” (see above) are used. If this option is active, the “sizex” graph-field is used for both the X and Y axis (“sizey” being ignored), essentially forcing fixed-aspect sized particles. With this option disabled, “sizex” and “sizey” act independantly allowing non-fixed aspect sized particles. |
|
pivotpoint |
setPivotPoint() |
This sets the pivot-point used to orientate the particle, particularly useful when the particle is spinning. The offset is from the top-left of the texture. “0.5 0.5” is the center of the particle, “1 1” is the bottom-right. Values greater than 1 can be used to create interesting rotational dynamics for particles, especially when they move. |
|
useBlending srcBlend dstBlend |
setBlending() |
This option controls the blending mode. When blending is active, the source/destination blending factors are used for all particles generated by this emitter. |
|
intenseparticles |
setIntenseParticles() |
This option overrides the blending mode (see "setBlending()" above). When active, the particles will render such that their intensity accumulates to white. This can produce a “bright” or “warm” glow effects. Note that particles rendered in this mode cannot be seen on a white background. Technically, this option activates blending and uses blending factors of "src=SRC_ALPHA" and "dst=ONE" so it's just a shortcut to a common blending option; obviously the same can be achieved by using the standard blending control. |
|
singleparticle |
setSingleParticle() |
This option forces the emitter to only create a single particle. The particle is always created as a “point” type. has a speed of zero (doesn’t move) and lives infinitely (until the effect is stopped). This can be useful when you want to create a single static effect using a single particle. Good for adding corona/glows to effects. |
|
fixedforce |
setFixedForceAngle() |
This options controls the angle used for the graph-field “fixedforce” (see above) that provides the ability to apply a constant force to particles. |
|
attachposition |
setAttachPositionToEmitter() |
This option attaches any particles to the emitter position (which is fixed at the effects position). Typically, if an emitter is moving, particles created move independantly. When this option is active, they move relative to the emitter. Note that this doesn’t affect the particles “orientation”. |
|
attachrotation |
setAttachRotationToEmitter() |
This option is used when the “attachposition” mode is active. Typically, particles rotate relative to the world such that zero is “up”. When this option is active, the particles additionally rotate around the emitter. Note that this doesn’t affect the particles “orientation”. |
|
rotateEmission |
setLinkEmissionRotation() |
This option will rotate the emission direction (see “emissionangle” and “emissionarc”) to that of the effect. Unlike “attachrotation” that depends on also using “attachposition”, this only rotates the emission and not the whole particle-system (all particles that are active). Therefore, only the emission direction is rotated. With this option active, rotating the effect results in a relative emission rotation as well. Note that all rotations are cummulative; using “attachrotation” and “rotateemission” results in the rotations being used together). |
|
effectemission |
setUseEffectEmission() |
This options controls whether the “emissionXXX” graph-fields are used from the emitter or the effect. This is described above in the effects-fields. |
|
firstinfrontorder |
setFirstInFrontOrder() |
This option controls the rendering order for particles. With this option active, the first particles to be created are in-front. Another way of saying the same thing is that with this option active, the oldest particles are in-front with newer particles appearing behind the older ones. With this option inactive, the reverse is true. Note that this option is only really useful when particles are not transparent but completely opaque. Also, there is no performance penalty for either option e.g. no particle sorting is taking place. |
Global Tweaking…
Now that you've seen all the functionality that's available from configuring the graphs, it's time to mention one last thing that you may find useful. It's a simple thing to get lots of effects and therefore particles up and running but one thing that you'll come across is the ability to bring your computer to its knees by having too many particles active. Worse, you may need to tweak the number of particles up or down dependent upon the computer your game is running on!
As you can see from above, you can scale each effect's “quantity_scale” graph to achieve this but if you've got lots of effects, it can be awkward to do this. To enable you to make global changes to the number of particles created, T2D provides the following preference:
“$pref::T2D::particleEngineQuantityScale”
This variable will scale the number of particles created by effects. A value of “0.5” will half the number of particles created. The default is “1.0” which doesn't change the quantity of particles created.
Collisions…
A feature that is most definitely advanced is the ability for particles to collide with objects in the scene. The following description assumes that you already know how to set up collision-detection on scene-objects.
Assuming you have already set up the effect-object to collide with objects in the scene, all you need to do to get the actual particles to collide rather than the effect-object is to issue the following command:
|
// Turn-Off “Effect” Collisions and use “Particle” collisions instead. // NOTE:- This option is “true” by default which causes the “effect” to collide. %effect.setEffectCollisionStatus(false);
|
After turning effect-based collisions off using the above command, all collision-detection will be particle-based. The result here would be that particle-effect objects will not collide with anything but their particles will. So how do you configure what objects these particles collide with? Easy, you've already done it: simply use the standard collision-methods against the “effect” object. In other words, the effect collision-settings are used to determine what its particles collide with. This method removes the need to have an alternate set of collision calls specifically for particles.
Now that you know how to activate particle-based collisions as opposed to effect-based collisions, there are a number of key differences that you should be aware of.
Only a specific set of collision-responses are available. If any unsupported collision modes are selected, no collision-response will occur but a collision-callback will still happen.
Only the following collision responses are available:
Clamp
Bounce
Sticky
Kill
Finally, when a collision occurs the following script will be called:
|
// “Particle” collisions Callback. // NOTE:- The standard “onCollision()” callback isn't processed! function onParticleCollision( %this ) { }
|
As you can see, the callback is not the standard callback of “onCollision()”. You'll also note that the only detailed provided is the effect-object itself. No hit-object, collision-normal or time is provided. The reason for this is because particle collision quantities can be huge and providing all this information in a single callback or indeed producing a callback for each and every particle that collides would soon bring any system to its knees!
Keep in mind that particle-collisions are currently meant for looks only and are not meant to provide detailed collision feedback. The above collision-callback is provided to at least provide a signal as to whether a collision occurred which could be used to manipulate the effect somehow.
Back to basics…
This document has taken you on a grand tour of the T2D particle-engine and as you can see, there’s a wealth of configurable parameters but in the end, most of this editing will be done in the particle-editor. Most of the time you’ll only do basic things when actually ‘using’ a particle-effect in your application so let’s spend a little time giving that kind of basic functionality some attention.
The stages of using a particle-effect are roughly split-up into four sections; create, load, play and stop. Let’s do the first two together as they’re so easy to decribe:
|
// Create a blank effect. %effect = new t2dParticleEffect() { scenegraph = mySceneGraph; }; // Load our fire-effect from disk. %effect.loadEffect( “fire.eff” );
|
As you can see, it’s pretty simple to get to this point. The “loadEffect()” method will load a complete particle-effect from disk and get it ready to go. These disk effects are typically saved using the particle-editor but can equally come from ‘manually’ created effects using “saveEffect()”. You could, for instance, load an effect created with the particle-editor, tweak some settings in script and then save the effect, perhaps with a different name, back to disk, it’s totally up to you.
Now that we’ve got a particle-effect object, all we really want to do with it is to play the effect. We do this with the following:
|
// Play our effect. %effect.playEffect()
|
That’s it! You should note that it is at this point when the timelines for graph-fields start. Next we want to stop the effect. We do this will the following:
|
// Stop our effect. %effect.stopEffect()
|
Again, that’s it. This is too easy so let’s discuss some of the finer-points of handling particle-effect objects. The first thing to note is that the effect-object is like any other T2D object in that when you’ve finally finished with it, you should “safeDelete()” it (see reference documentation). The method “stopEffect()” tells the effect to stop creating particles, it doesn’t destroy the effect.
The stopping of effects raises an interesting dilemma. When we stop the particle-effect, what do we do with the particles that are still alive? Do we remove them? Do we wait for them to die naturally? If we remove them immediately, we’ll see particles simply disappear which looks unnatural. We’d want them to die naturally but we don’t know how long to wait; help!! The good news is that T2D allows you to choose and will handle it for you!
The “stopEffect()” has two optional parameters that allow finer control of this situation like so:
|
// Stop our effect. %effect.stopEffect( true, true )
|
As you can see, we’ve got two flags to choose from. The two flags are called “WaitForParticles?” and “KillEffect?” respectively.
When “WaitForParticles?” is true, the effect will immediately stop emitting particles but will wait for any existing particles to die naturally before finally signaling the effect as stopped. This is extremely handy and the most typically used configuration. When this is false, particles will be removed immediately.
When “KillEffect?” is true, the effect will automatically be deleted when the effect stops. If you are ‘waiting for particles’, the effect will be deleted when all particles have died naturally.
So our call above would result in any particles currently active, when we stop the effect, to die naturally, immediately followed by the effect being destroyed. This is neat housekeeping as you can stop and forget the effect.
There is an additional option in the “playEffect()” method called “ResetParticles?”. This is very handy if you stop an effect and then proceed to play it again. In this situation, you may want any existing particles to be either cleared or allowed to die naturally as we did with the “stopEffect()” method. The difference here is that the effect will immediately start playing, creating new particles, whilst the older particles continue their life as normal.
This can be handy for “thruster” effects that are turned on/off. You would do this by starting/stopping the effect, maybe as the player hits the ‘thrust’ key. In this case, you’d typically want the effect to leave any existing particles alone so you’d use:
|
// Play our effect. %effect.playEffect( false )
|
Note that the default is to clear particles when playing an effect.
Another option that is very handy in controlling the life of an effect and its particles is “setEffectLifeMode()”. All life-modes, with the exception of “kill” mode, can be configured in the particle-editor but it is very handy to understand exactly how it works. There are four ‘life-modes’ that an effect can use, these are “INFINITE”, “CYCLE”, “KILL” and “STOP”. Here are some examples:
|
// Set-up some life-modes. %effect1.setEffectLifeMode( INFINITE ); %effect2.setEffectLifeMode( CYCLE, 5.0 ); %effect3.setEffectLifeMode( KILL, 5.0 ); %effect4.setEffectLifeMode( STOP, 5.0 );
|
All modes control what happens to the effect after a period of time. “INFINITE” states that the effect will continue to play forever. “CYCLE” will cause the effect to restart continuously, forever, in this case every 5 seconds. “KILL” will cause the effect to be destroyed, in this case, after 5 seconds. “STOP” will cause the effect to simply stop, in this case, after 5 seconds. All times are from the point when the effect is first started. Note that the “CYCLE”, “KILL” and “STOP” modes all wait for particles to die naturally (see above).
Although not strictly needed, it is interesting to note how each emitter controls the “area” in which it creates particles. Each emitter has a method “setEmitterType()”. The description for this method can be found above (and in the reference documentation) but it is not immediately obvious how the physical area is defined.
Let’s apply the following method to our effect (assume all emitters have type set to “area”):
|
// Set our effect size. %effect.setSize( “200 150” );
|
Setting the ‘size’ of an effect probably won’t do what you may first expect. Because effects don’t actually render anything, its ‘size’ doesn’t seem to control anything; it certainly doesn’t change the size of particles, there are graph-fields for those settings. So what does it do? Well, it’s actually quite simple to understand. The ‘size’ of an effect is used by all its emitters. When you set an emitter to “area”, “linex, or “liney”, the physical area uses the parent effects’ size. It essentially sets the physical region that defines the “area” or “linex/y”.
The method above would set an area of “200 x 150” in the world. If the emitter was set to “area”, the particles would be created within an area of “200 x 150” at the effect's current position. If the emitter was set to “linex”, the particles would be created along a line, centered on the effects current position, from -100 to +100 in the X-axis and 0 in the Y-axis. The “liney” type is identical to “linex” but along the y-axis.
And finally…
So we’ve taken the grand-tour of the T2D particle-engine and you may be thinking that we’ve covered pretty much everything but that isn’t the case. There is so much more to discover but thankfully, it’s all creative discovery because with all these configurable parameters at your disposal, you should be able to generate some completely amazing effects.
If you come up with some great effects and you don’t mind sharing then be sure to post them as a resource, maybe even a particle-effects pack. You never know, we may even include them in the SDK and make you famous.
Good luck and enjoy the T2D particle engine.


Use location service?
Let us help determine location. This means sending anonymous location data to us, even when no apps are runnig.


--- layout: post title: Automatic retries in NServiceBus date: 2011-11-21 15:34:49.000000000 +01:00 categories: [] tags: [] status: draft type: post published: false meta: _edit_last: '1' author: login: andreas.ohlund email<EMAIL_ADDRESS>display_name: Andreas Öhlund first_name: Andreas last_name: "Öhlund" ---
*Transient vs non transient
*How this affects the UoW


The London Eye is turning pink in 2020 (at night, anyway)
by By El HuntJust when you thought ‘millennial pink’ was over, things are looking rosy for one of London’s most famous landmarks.
Joining the esteemed company of Sketch’s interiors and the oft-Instagrammed bubblegum staircase at Frank’s Café, the London Eye will sport a fetching shade of pink from February onwards, after dark, at least.
The wheel’s new sponsor is travel company Lastminute.com, who will be shaking things up when it takes over in February – and that includes reworking the Eye’s night-time illumination with its hot-pink brand colour.
It’s certainly a more soothing prospect than the current fiery glow. Since 2015, the Coca-Cola London Eye (as it is, of course, known by all Londoners) has been lit up bright red at night to match its fizzy sponsor. Stumbling across the Golden Jubilee footbridge after a couple of pints in Covent Garden, anybody could be forgiven for mistaking the huge structure for something from ‘Lord of the Rings’.
‘The Lastminute.com London Eye’ probably won’t catch on as a name among real people any time soon, but the landmark’s new look will stick around for at least the next three years. Talk about pretty in pink.
Sign up here to get the latest from London straight to your inbox.


Pig Latin Translator
Enter your sentence below:
Submit Sentence
Here is your sentence translated to Pig Latin:


Bacon ipsum dolor amet porchetta turducken kielbasa fatback landjaeger capicola corned beef flank sausage pork prosciutto chuck ground round.  Brisket strip steak prosciutto pork belly andouille short loin beef chuck jerky filet mignon fatback alcatra ribeye. Pancetta meatloaf kevin sirloin.
Alcatra rump pork, corned beef turkey meatloaf drumstick. Leberkas pork spare ribs, ham hock hamburger cupim prosciutto flank corned beef pork loin. Biltong andouille pork belly, filet mignon pork chop shank cow turkey. Boudin capicola pork, swine kevin ground round tri-tip chuck t-bone. Meatloaf sirloin pastrami boudin pork loin bacon shank strip steak meatball.
Jowl cupim hamburger, corned beef fatback pork chop porchetta sausage boudin cow shoulder frankfurter pork belly ham hock strip steak. Shank sirloin pork chop pig, beef ribs ground round pork spare ribs frankfurter biltong short ribs boudin tail brisket. Pig boudin ball tip sirloin, ground round spare ribs filet mignon leberkas andouille pork belly. Biltong hamburger capicola t-bone chicken ground round. Landjaeger jerky cupim shank t-bone salami.
 Porchetta ribeye shankle sausage tongue bresaola. Bresaola bacon cow boudin cupim swine shoulder pork belly alcatra filet mignon ball tip short ribs strip steak. Strip steak pork loin ribeye pastrami capicola pork. Bresaola leberkas pig beef ribs. Pancetta kielbasa fatback burgdoggen beef ribs ribeye.
Bacon cupim burgdoggen, pork belly shankle sirloin beef ribs venison meatloaf chuck spare ribs picanha boudin. Picanha boudin salami brisket, bacon cupim porchetta short ribs venison prosciutto beef andouille. Strip steak ham shoulder meatloaf short loin tail turducken fatback andouille pork pastrami landjaeger biltong sirloin turkey. Turkey ham hock bresaola tongue. Kevin pork loin ribeye venison pork rump tenderloin ball tip hamburger chuck doner shoulder spare ribs turkey. Strip steak sirloin porchetta tri-tip kielbasa jowl andouille biltong.


By now the user should have a copy of the project on his machine. If not refer to section: Getting Started
There are two ways of running the software on windows:
Running the executable is as simple as running the Pump3000.exe located in the <location_to_project>/python_code/dist folder [1] [2].
Alternatively, the user can run the software from source. This requires the execution of a full python distribution. It is advised that the user uses one of the following distributions due to the simplicity of the installation process
The user must also have the following packages installed:
For the Anaconda distribution the user can install packages from the Command line using one of the following ways [3]
$conda install <package_name>
$pip install <package_name>
Finally, the user should run the software using the command prompt:
python <location_to_project>\python_code\Pump3000.py
In case the user wants to run the software from a *NIX environment, a basic python distribution must be installed on the platform, (already preconfigured on most *NIX systems). The user must also have the following packages installed:
After this configuration, the user can run the software from the command-line [*NIX] command-prompt [Windows]:
python Pump3000.py
Note that the user should first go to the folder, the Pump3000.py is located.
The first thing the user should do, if he doesn’t know the serial connector to the pump, is figure out the correct port:
On Windows machines this can be done by getting the ‘Ports (COM & LPT)’ tab:
Start Menu > right-click "My Computer" > select "Manage" > Click on the "Device Manager"
(On the "Device Manager") Click "Ports (COM & LPT)" tab > select the port your connector is on
On *NIX machines this can be done the following way:
cd /dev
ls -lart| grep tty
This will give you a list of the currently available ports. Ejecting and reinserting the connector to the computer and in the meantime running the second command again will help you recognise the port the pump is running on.
Warning
Make sure that you have selected the correct port, otherwise the pump will not respond and will not raise any error Message
After that you are ready to run the software (whichever way you want). You should be directed to the New_Device window where the port connected to the pump must be selected
If you have selected the correct port, the connection to the pump is established and the software will automatically initialize the pump, by moving the plunger to the upper position.
You are now in the Main Window. From here you can:
From the main window you can navigate to a series of other dialogs:
Editor’s Tab
The Editor’s Tab gives the user the ability to issue a series of commands to the pump. These commands are supplied in the “Pump Commands” page. The user can also issue raw pump commands in the same way.
A typical example of issued commands would be the following:
pump.property_set('speed', '5')
# Python Comments, write as many as you want
# Empty lines don't matter
# Raw commands as well
/1?2R\r
pump.send_Command('A0')
History
From here the user can see all the commands sent to the pump which can be divided to 2 types:
Syringe Size
The user can decide the syringe size.
Reports
Gives the user an overview of the pump currently configured settings
Pump Parameters
The user can change certain parameters of the plunger movement such as “Top Velocity”, “Slope” etc.
Port
The user can configure the port that the pump is connected to. This window is also summoned at the start of the Pump30000
Footnotes
| [1] | You can make a shortcut to Pump.exe file but do not move it outside the dist folder as it depends on the dlls files located there |
| [2] | If the executable doesn’t run correctly, try installing the vcredist_XXX file. Replace the XXX with the architecture of your processor. The vcredist files are located in the vcredist directory. After the installation, rerun the executable. If the problem persists, contact me |
| [3] | Consult the instructions on the site of the corresponding distribution for more details on installing packages |


About Me
Hi! My name is Poonam Mehra and I am a full-stack software developer located in San Francisco. With skill to work in both front end and back end web developmemnt. On my free time I enjoy traveling and trying new food.
Hi! My name is Poonam Mehra and I am a full-stack software developer located in San Francisco. With skill to work in both front end and back end web developmemnt. On my free time I enjoy traveling and trying new food.


Unless you follow mid-major conferences closely, when it comes time to picking first round upsets in the NCAA Tournament you’re likely either picking teams at random, or going off the analysis of the “experts” on TV, the internet, or podcasts. I won’t address those who pick their upsets and Cinderella teams at random here, instead this post is about those who combine whatever they know about the field in a given year with what they see, read, and hear in the media. If you consume a lot this media you may be tempted to pick a lot of upsets, however by definition they should be rare.
Thanks to a dataset from a Kaggle competition that provides tournament results from 1985-2016, I’ve put together an analysis that aims to offer guidance on how many upsets you could expect in the first round, and from which matchups they come from. I define an upset to be anytime a numerically higher seeds beats a numerically lower seed (e.g. a 10 seed beats a 7 seed).
Data Prep
Load libraries and data
library(tidyverse)
library(magrittr)
library(knitr)
results <- read_csv(file = paste0(data_path,"TourneyCompactResults.csv"))
seeds <- read_csv(file = paste0(data_path,"TourneySeeds.csv"))
slots <- read_csv(file = paste0(data_path,"TourneySlots.csv"))
seasons <- read_csv(file = paste0(data_path,"Seasons.csv"))
colnames(results) <- tolower(colnames(results))
colnames(seeds) <- tolower(colnames(seeds))
colnames(slots) <- tolower(colnames(slots))
colnames(seasons) <- tolower(colnames(seasons))
Light data cleaning
# convert colnames to lowercase
colnames(results) <- tolower(colnames(results))
colnames(seeds) <- tolower(colnames(seeds))
colnames(slots) <- tolower(colnames(slots))
colnames(seasons) <- tolower(colnames(seasons))
# parse the seed variable to get the region and numeric seed
seeds %<>%
mutate(region = str_sub(seed,1,1),
seed = as.numeric(str_sub(seed,2,3)))
Restructure the data
results2 <-
results %>%
select(-daynum,-wscore,-lscore,-numot) %>% # drop uneeded variables
inner_join(., # append winning team seeds and regions
seeds %>% rename(wseed = seed,wregion = region),
by = c("season","wteam" = "team")) %>%
inner_join(., # append losing team seeds and regions
seeds %>% rename(lseed = seed,lregion = region),
by = c("season","lteam" = "team")) %>%
mutate(matchup = paste0(pmin(wseed,lseed),"-",pmax(wseed,lseed)),# create new variables indicating the matchup
upset = ifelse(wseed > lseed, 1,ifelse(wseed == lseed, 0.5,0))) %>% # and if it was an upset
select(season,matchup,upset,wregion,lregion)
head(results2)
## # A tibble: 6 x 5
## season matchup upset wregion lregion
## <int> <chr> <dbl> <chr> <chr>
## 1 1985 8-9 1 X X
## 2 1985 6-11 1 Z Z
## 3 1985 1-16 0 W W
## 4 1985 8-9 1 Y Y
## 5 1985 3-14 0 Z Z
## 6 1985 5-12 1 X X
Total First Round Upsets
The first question to consider is how many upsets there are in a typical tournament. First we’ll aggregate the data to count the number of upsets by season.
total_upsets <- results2 %>%
filter(matchup %in% c('1-16','2-15','3-14','4-13','5-12','6-11','7-10','8-9'), wregion==lregion) %>%
group_by(season) %>%
summarise(total_upsets = sum(upset))
Then, plot them.
ggplot(data = total_upsets,
aes(x = total_upsets)) +
geom_bar(fill = "orange") +
scale_x_continuous("Total First Round Upsets",
breaks = c(3,4,5,6,7,8,9,10,11,12,13)) +
scale_y_continuous("Percent") +
ggtitle("Number of Total First Round Upsets", sub = "NCAA Men's Tournament, 1985-2016") +
theme_minimal()
The obervations here are:
- There has always been at least 3 and never more than 13 total first round upsets.
- There have been between 7 and 10 (inclusive) upsets in rougly 2 out of every 3 (21/32) tournaments.
- It has been more likely to have fewer than 7 upsets 7/32 than more than 10 (4/32).
Total Upsets By Matchup
The second question is from which matchups are most upsets sourced? To determine this question we’ll aggregate the data as before but add the additional level of aggregation of matchup.
by_matchup <- results2 %>%
filter(matchup %in% c('1-16','2-15','3-14','4-13','5-12','6-11','7-10','8-9'), wregion==lregion) %>%
group_by(season,matchup) %>%
summarize(upsets = sum(upset))
Again, plot these data.
ggplot(data = by_matchup,
aes(x = upsets)) +
facet_wrap(~matchup,ncol = 4) +
geom_bar(fill = "orange") +
scale_x_continuous("Upsets") +
scale_y_continuous("Count") +
ggtitle("Number of Upsets Each Year By Matchup",sub = "NCAA Men's Tournament, 1985-2016") +
theme_minimal()
Some oberservations from this chart:
- The most likely outcome every year is:
- 0 upsets of 1 and 2 seeds
- at least one upset of each of teams seeded 3-7
- a tie of either 1 or 2 upsets of an 8 seed by a 9 seed.
Historical Trends in Upsets
For those who have been following basketball for a while, an as of yet unaddressed consideration is the way college basketball has changed during the period represented in the data. The best players in the country have gone from staying in school for three or four years to playing only a single season. Sometimes, it seems now, higher seeded teams that may not have a lot of NBA caliber talent, but have more experience and chemistry, could have a better chance of upsetting teams with rosters with less chemistry but more individual talent.
To address this we’ll look at the data in each of the first two plots but with an added component of time.
ggplot(data = total_upsets,
aes(x = season, y = total_upsets)) +
geom_point(colour = "orange") +
geom_line(colour = "orange") +
geom_smooth(method = "loess") +
scale_x_continuous("Season",minor_breaks = c(1985:2016)) +
scale_y_continuous("Upsets", breaks = c(3:13)) +
ggtitle("Number of Total First Round Upsets By Year", sub = "NCAA Men's Tournament, 1985-2016") +
theme_minimal()
Some observations from this plot:
- For most of the tournament the best guess of the total number of upsets is somewhere between 7 and 9 (inclusive)
- 5 of the 8 times there have been at least 10 first round upsets have happened since 2009.
- To that point, there is a slight trend upwards in recent years. That could justify picking more upsets than the historical record would indicate if recent time-trend data weren’t considered.
The second plot considers the number of upsets by matchup over time.
ggplot(data = by_matchup,
aes(x = season, y = upsets)) +
facet_wrap(~matchup,ncol = 4) +
geom_line(colour = "orange") +
geom_point(colour = "orange") +
geom_smooth(method = 'loess') +
scale_x_continuous("Season") +
scale_y_continuous("Upsets") +
ggtitle("Number of Upsets By Season and Matchup",sub = "NCAA Men's Tournament, 1985-2016") +
theme_minimal()
Some observations from this plot:
- In the last few years there appears to be a trend for an increased likelihood of upsets in the 2-15 and 3-14 games going from zero to one upset.
- A trend for upsets in 5-12 games appears to have been a slow, ongoing phenomenon since the tournament began. Going from one in the 1980s to two today.
- A trend for an upset in 6-11 games appears to have begun back around the year 2000, going from one at the time to two today.
Trends in the 2-15 and 3-14 games are very recent, whereas at least visually the 5-12 and 6-11 games appear to have more support.
Suggested Approach to Picking First Round Upsets
Based on this analysis you could use the following heuristic for selecting how many upsets to pick and in which matchups to pick them. I’m going uitilize the apparent trend in increase of upsets in 5-12 and 6-11 matchups that was seen in the plot above. Of course which individual games to select requires some additional analysis.
Some resonable guidlines are presented in the table below.
| Matchup | Recommended Upsets to Pick |
|---|---|
| 1-16 | 0 |
| 2-15 | 0 |
| 3-14 | 0/1 |
| 4-13 | 1 |
| 5-12 | 2 |
| 6-11 | 2 |
| 7-10 | 1/2 |
| 8-9 | 1/2 |
| ——— | —————————- |
| Totals | 7-10 |
These recommendations based in individual matchups place the total number of upsets selected in the range of most frequent number of upsets.
Conclusion and Further Work
In the course of doing this analysis I had some ideas for possible extensions:
- Extend this analysis into the Round of 32 and beyond
- Compare chalk vs random upset picking based on these heuristics on the traditional bracket scoring.
- Expand the analysis with a Bayesian flavor, using appropriate prior and conjugate distributions for likelihoods of upsets by matchup and total number of upsets.
Postscript
The first round of the 2018 tournament has come and gone. Below is a table showing my recommendations for number of upsets along with how many upsets actually happened.
| Matchup | Recommended Upsets to Pick | Upsets in 2018 |
|---|---|---|
| 1-16 | 0 | 1 |
| 2-15 | 0 | 0 |
| 3-14 | 0/1 | 0 |
| 4-13 | 1 | 2 |
| 5-12 | 2 | 0 |
| 6-11 | 2 | 1 |
| 7-10 | 1/2 | 1 |
| 8-9 | 1/2 | 3 |
| ——— | —————————- | —————- |
| Totals | 7-10 | 8 |


;/2
[ISO]+P ;
+Q
Disjunction: Succeeds if P succeeds or Q succeeds.
+P ->
+Q ;
+R
If P then Q else R, using first solution of P only.
These are normally regarded as part of the syntax of the language, but
they are like a built-in predicate in that you can write
call((
P ;
Q))
or call((
P ->
Q ;
R))
.
The character `|' (vertical bar) can be used as an alternative to `;'.
The operator precedences of the `;' and `->' are both greater than 1000, so that they dominate commas.
Cuts in P do not make sense, but they are allowed, their scope being the goal P. The scope of cuts in Q and R extends to the containing clause.
For the if-then-else construct: if P succeeds and Q then fails, backtracking into P does not occur. A cut in P does not make sense. `->' acts like a cut except that its range is restricted to within the disjunction: it cuts away R and any choice points within P. `->' may be thought of as a “local cut”.
Call errors (see ref-sem-exc).


Thank you for signing up to our service
You will recieve an email once your account has been actived
Thank you very much, you should be redirected to hompage shortly


search
home
home
feed
feed
videocam
videocam
music_note
music_note
shopping_bag
shopping_bag
shopping_cart
shopping_cart
Login
Login
Login
Login
Login
Login
Login
search
home
home
feed
feed
videocam
videocam
music_note
music_note
shopping_bag
shopping_bag
shopping_cart
shopping_cart
first name
expand_more
Edit Profile
Purchase
History
Logout
first name
expand_more
Edit Profile
Be an Artist
Purchase History
Logout


Home
Products
Cart
Game
About us
Welcome To Your Cart
Here Is A List Of All The Products You Buy !

Donate 1 $
Draw Smile ^^


Numbers 28:24
After this manner ye shall offer daily, throughout the seven days, the meat of the sacrifice made by fire, of a sweet savor unto the LORD: it shall be offered beside the continual burnt offering, and his drink offering.


Tip Calculator
How much was your bill ?
₹
How was your service ?
Select
30% - Outstanding
20% - Good
15% - It was ok
10% - Bad
5% - Terrible
How many people are sharing the bill?


pytma package¶
Submodules¶
pytma.Featurize module¶
pytma.Lemmatize module¶
-
class
pytma.Lemmatize.
Lemmatize
¶ Bases:
object
Lematizer class: Wordnet or spacy
-
get_nltk_POS
(self, word)¶ Get the part of speech
- Parameters
word –
- Returns
-
lemmatize_nltk_with_POS
(self, text)¶ lemmatizes with nltk - using the POS
- Parameters
text –
- Returns
-
lemmatize_spacy
(self, text)¶ Lematizes using spacy
- Parameters
text –
- Returns
-
porter_stemmer
(self, text)¶
-
pytma.Parse module¶
-
class
pytma.Parse.
ParseText
(text)¶ Bases:
object
Class for parsing text. Uses spacey.
-
chart_parse
(self)¶ Chart parse :return:
-
dependency_parse
(self)¶ Dependency parser : Analyzes the grammatical structure of a sentence, establishing relationships between “head” words and words which modify those heads :return:
-
display_parse
(self)¶ sets up web page with parse diagram :return:
-
noun_chunks
(self)¶ Looks for n-gram noun phrases Think of noun chunks as a noun plus the words describing the noun – for example, “the lavish green grass” or “the world’s largest tech fund” :return:
-
pytma.POSTag module¶
pytma.Predict module¶
pytma.Preprocess module¶
-
class
pytma.Preprocess.
Model
(func=<function cumgauss>)¶ Bases:
object
Class for fitting cumulative Gaussian functions to data
-
class
pytma.Preprocess.
Fit
(model, params)¶ Bases:
object
Class for representing a fit of a model to data
-
predict
(self, x)¶ Predict values of the dependent variable based on values of the indpendent variable.
- Parameters
- xfloat or array
Values of the independent variable. Can be values presented in the experiment. For out-of-sample prediction (e.g. in cross-validation), these can be values that were not presented in the experiment.
- Returns
- yfloat or array
Predicted values of the dependent variable, corresponding to values of the independent variable.
-
-
pytma.Preprocess.
opt_err_func
(params, x, y, func)¶ Error function for fitting a function using non-linear optimization.
- Parameters
- paramstuple
A tuple with the parameters of func according to their order of input
- xfloat array
An independent variable.
- yfloat array
The dependent variable.
- funcfunction
A function with inputs: (x, *params)
- Returns
- float array
The marginals of the fit to x/y given the params
-
pytma.Preprocess.
transform_data
(data)¶ Function that takes experimental data and gives us the dependent/independent variables for analysis.
- Parameters
- dataPandas DataFrame or string.
If this is a DataFrame, it should have the columns contrast1 and answer from which the dependent and independent variables will be extracted. If this is a string, it should be the full path to a csv file that contains data that can be read into a DataFrame with this specification.
- Returns
- xarray
The unique contrast differences.
- yarray
The proportion of ‘2’ answers in each contrast difference
- narray
The number of trials in each x,y condition
-
pytma.Preprocess.
cumgauss
(x, mu, sigma)¶ The cumulative Gaussian at x, for the distribution with mean mu and standard deviation sigma.
- Parameters
- xfloat or array
The values of x over which to evaluate the cumulative Gaussian function
- mufloat
The mean parameter. Determines the x value at which the y value is 0.5
- sigmafloat
The variance parameter. Determines the slope of the curve at the point of Deflection
- Returns
- gfloat or array
The cumulative gaussian with mean \(\mu\) and variance \(\sigma\) evaluated at all points in x.
Notes
Based on: http://en.wikipedia.org/wiki/Normal_distribution#Cumulative_distribution_function
The cumulative Gaussian function is defined as:
\[\Phi(x) = \frac{1}{2} [1 + erf(\frac{x}{\sqrt{2}})]\]Where, \(erf\), the error function is defined as:
\[erf(x) = \frac{1}{\sqrt{\pi}} \int_{-x}^{x} e^{t^2} dt\]
pytma.Sentiment module¶
-
class
pytma.Sentiment.
Sentiment
¶ Bases:
object
Sentiment analyzer. Supervised via NaiveBayes or unsupervised via Valence method.
-
naiveBayesSentimentFit
(self, text)¶ Supervised sentiment analysis - uses nltk to fit Naive Bayes . Call naiveBayesSentimentPredict to predict using the latest fit model.
- Parameters
text –
- Returns
-
naiveBayesSentimentPredict
(self, text)¶ Predicts sentiment. Call naiveBayesSentimentFit on a corpus first otherwise an error will be thrown.
- Parameters
text –
- Return predicted sentiment
-
valenceSentiment
(self, text)¶ Unsupervised sentiment analysis.
- Parameters
text –
- Return sentiment polarity scores
-
pytma.Tokenization module¶
pytma.TopicModel module¶
-
class
pytma.TopicModel.
LDAAnalysis
(docs, num_topics=5, chunksize=500, passes=20, iterations=400, eval_every=1)¶ Bases:
object
-
coherence_values
(self, limit=40, step=6, start=2)¶
-
compute_coherence_values
(self, limit=40, start=2, step=3)¶ Compute c_v coherence for various number of topics
dictionary : Gensim dictionary corpus : Gensim corpus texts : List of input texts limit : Max num of topics
model_list : List of LDA topic models coherence_values : Coherence values corresponding to the LDA model with respective number of topics
-
docs_preprocessor
(self)¶
-
fit
(self, dictionary_filter_extremes_no_below=10, dictionary_filter_extremes_no_above=0.2)¶
-
topic_coherence
(self)¶
-


Roland JV-80 / JV-880
Single Patch Editor
This patch editor ought to work properly with both the JV-80 and the JV-880. However it has only been tested with the JV-880. Please let me know of any discrepancies you discover.
Communicating with Edisyn
Be sure to have the patch/perform button on your JV-80/880 set to "patch". When you set up MIDI in the patch editor, you can specify the MIDI channel and the Synth ID. Set your synthesizer's Patch Receive channel ("Rx channel", which appears under the System menu ONLY when in Patch Mode, and not to be confused with the Control Channel) to the same as Edisyn's channel (perhaps Channel 1), and its "Unit number" to the same as Edisyn's Synth ID (perhaps 17). Set Program Change, Bank Select, and Exclusive to ON. Make sure write protect is off if you want to write changes. Finally, make sure the Edit button is OFF or your JV won't respond properly.
Gotchas
- Changing patches on the Roland JV880 is SLOW: perhaps 2 seconds, because each step (changing to "Patch" from "Perform", setting the bank, and finally doing a Program Change) requires about 700ms of wait time afterwards or else the machine will get confused. Thus uploading and downloading patches will be very slow.
- You can't edit, and sometimes can't play notes, unless the Patch/Perform button is set to "Patch". Edisyn tries to set this button programmatically when it can, but sometimes it won't get set -- for example, when you just change windows from the Multi editor to the Single Editor. So if you're having difficulty, make sure the button is properly set.
Librarian Support
In order to download one patch, Edisyn must (1) change the patch/performance button to "patch" (2) send a change-bank request (3) send a program-change request (4) load the patch. The problem is that each of these tasks requires about a 700ms break afterwards or the JV-880 can get confused. As a result, loading patches into the Librarian at present is very, very slow: about 2-3 seconds per patch. I'm sorry about that.
Also note that if the JV-880 has failed to do any of these tasks, when Edisyn loads the patch proper, it'll load the previous patch. That's why, when you try to load all patches, the "Card" bank gets loaded with dummy patches equivalent to the last patch in the Internal bank: because they've all failed (there's no card).
Thanks
Thanks to Keith<EMAIL_ADDRESS>for his extraordinary service in loaning a machine in a pinch, providing materials, and debugging.  Thanks also to Phillip Smith<EMAIL_ADDRESS>for assistance in debugging with the 1.0 firmware.
| By
| Sean Luke
|
| Date
| April 2019
|


{{ event.title }}
{% if event.summary %}{{ event.summary|safe }}
{% endif %}Google Developers Group Cebu (GDG Cebu) is a non-profit group of amateurs and professionals in Cebu's developer community who are passionate about Google technologies. GDG Cebu has previously organized multiple events, ranging from campus talks and viewing parties, to larger ones such as last year's DevFest, which drew more than a thousand attendees.
On February 25, 2017, GDG Cebu will be holding its biggest event yet—the GDG Cebu Code Camp.
The Code Camp will run from 9am to 5pm and focus on essential technical topics for developers, along with updates on the current development trends. The topics will range from Machine Learning, Firebase, and the Cloud, to Material Design, Android, and 2017's Web Trends.
For this special event, attendees will be learning about these topics from Googlers (Google employees) themselves, who will be flying in from South Korea, Japan, Singapore and the US.
For the estimated 1,500 developers, tech enthusiasts, students, etc. who will attend, the Code Camp will be a great opportunity to learn about the latest technologies straight from Google’s experts. Additionally, developers from Cebu and around the Visayas will also get to meet and interact with one another, leading to sharing, possible collaboration and the enlivening of Cebu’s tech scene.
The GDG Cebu Code Camp will be held at the IEC Convention Center Cebu, Pope John Paul II Ave., Cebu City..
{{ event.summary|safe }}
{% endif %}


Number of responses:
Statistics: {{100*survey.q1count1/(survey.q1count1+survey.q1count2+survey.q1count3) | number:2}}%
Number of responses:
Statistics: {{100*survey.q1count2/(survey.q1count1+survey.q1count2+survey.q1count3) | number:2}}%
Number of responses:
Statistics: {{100*survey.q1count3/(survey.q1count1+survey.q1count2+survey.q1count3) | number:2}}%