I'm giving it the full thumbs-up (once you've moved the get/set blocks 
)
When you do launch - I'd start a new thread as this one has probably been muted by most people by now
1 Like
Indeed. I already planned to create a new thread when I publish it on NPM. But do you really think that the entire Node-RED community is currently neutralized, and nobody is following this discussion anymore? There is only one way to check whether you are right: anybody that adds a like 
to this post within 24 hours, will get a free bottle of champagne from Simon!
Deal! On Github you can find a new version with following changes:
-
The property-get/set blocks have been moved from the 'Object' category in the toolbox to the 'Node-RED' category:
-
I installed the awesome Node-RED 0.19 version, but seemed that I had forgotton to update my sandbox code to offer the new node.id and node.name properties in the limited API. But that is now solved:
If this is fine for everybody, I will restart my documentation work ....
Bart
7 Likes
Seems reasonable to me 
2 Likes
PS new one works (once I'd done the global search/replace on the flow.json) so you are still good to go
A very very very small suggestion when you publish to NPM
maybe should have a default text block instead of being empty
Would help users work out which block goes from JSON to JS object and which goes from JS Object to JSON
I created last week already a series of tutorials on my wiki page. Keep in mind that this is currently in DRAFT status:
- Extra tutorials need to be added
- Some of the tutorials are already obsolete, due to my developments in the last week.
- A table of content page need to be added
- ...
Would like to have some feedback about the animated gifs: they are very useful to explain to a novice user how to drag and drop the blocks to his editor. However you cannot pause them, or go back to the start ... It is even not visible whether you are at the beginning, or in the middle of the movie ... And perhaps it is annoying for some users to have all the movements on the screen. Some random thoughts:
- Is it better to show a real movie, like the Node-RED version 0.19 movie from @knolleary . If yes (?) how to record the screen, where to store the movies (on Github wiki?), how to show them in the wiki? ...
- Or just show a screenshot of the blocks, and add e.g. a button to open the animated gif in a new browser window? Then you can determine when the animated gif needs to start.
- others ???
Just want to avoid that I spend a lot of spare time to the documentation, and everybody thinks it is complete rubbish ...
@BartButenaers I added a 
to your post within 24 hours ... I'm gonna need that bottle of champagne you've been talking about ... the good news is that I'm in Belgium too so shipping won't cost you too much ... just kidding ... just wanted to post to say that "other" people are following your "experiments" without necessarily being active on this post .... this looks promising, keep up the good work !
I don't normally EVER watch a video but I will watch a gif because they are normally short and to the point. So I like your GIFs when they are short
I do post vids myself on Youtube and then link to them on twitter so if your going to do videos then I'd embed youtube videos (if you can)
Keep the number of images/gifs/videos down as you WILL have to update them again
Try to keep them simple and without extra annotation
I will do a series of tutorials from beginners point of view and show how flows with several standard nodes can be compressed into a single blocky node. I'll fork your wiki and do pull requests
its me that is buying and I live in UK 
They look OK to me, not too fast which is when they get really annoying.
Personally, I'd stick with what you've got for now. If you wanted to do a video, maybe come up wth a nice example to create. But you don't have to answer every question just to publish a first version. People will expect some limitations on first release. Better to get it out now so that others can find issues, make suggestions and ask for help (so you know where you may have documentation gaps or need a vid).
Yes I know that it's very tempting for me to develop years on version 1, until it contains all functionality (e.g. launch rockets to other solar systems...). But about the new version from yesterday: it contained breaking changes, so I would damage all existing flows. That kind of stuff needs to be in my first version!
I will start writing documentation again this evening, to make sure that I don't develop anything new 
2 Likes
Thought about this and began to think that it may be fundemental to Node-RED
Did a bit of googleing and found this
http://noderedguide.com/node-red-lecture-5-the-node-red-programming-model/#h.n0q1bv7ofyil
which I managed to translate to this
which works 
ONCE THE PROJECT IS LAUNCHED ON NPM AND NOT BEFOREHAND I think it would be nice to have a list block to match msgList.push({payload:i}); i.e the .push bit
Not for me it didn't!
I'll make a smal wager that you don't have the rate limiter in your flow
Don't think that is needed.
However, a nice enhancement would be a generic list "push", "pop" blocks.
Thats what I meant - generic block not specfic for this task
Ah, well of course that would jump since a simple loop will execute in a fraction of a second!
The problem is that the msg object is being reused - this is a JavaScript issue, not a Node-RED one.
1 Like
Thought it might be something like that - I really struggle, at times, to get my head around the non-sequential behaviour of JS
But JS programmers will have it made when quantum computing takes off
This is the code that should be being used:
for (i = 1; i <= 5; i++) {
var msg1 = {'payload': i};
node.send([msg1]);
}
Note the inner use of var which ensures that each msg is unique.
If you wanted to make sure that each msg inherited the incoming msg, you would need to do a deep copy of the msg object. There is a utility function for that attached to the RED object.
