Plumber

As a typical Brit who has only a smattering of schoolboy French, the level of English used here never ceases to amaze me!

It is my opinion that TLG behaviour over the last few years has made it increasingly clear that they see MOC builders who buy only parts on the secondary market as an unprofitable cohort and as (in the technic forum at least) many post this creed it is not surprising to me they have withdrawn support here. TLG have moved on and I see no issue with Eurobricks doing the same. As regards MOC's from alternative manufacturers parts, the lack of a secondary market place like Bricklink/Owl (or even a parts catalogue) severely hampers the ability of MOCers to build with their product, I am firmly of the opinion that TLG purchased BL purely to prevent other makes from becoming more widely available. While there are a number of third party resellers of Gobricks there sites are chaotic and feature major variances in available parts and colours. Aliexpress etc.is a source but is even more chaotic. Given the above reality I do not see there being a sudden upsurge in the number of Alt.MOCs if they become permissible and therefore while I voted for option 3 I am increasingly persuaded by 2GodBDGlory's view that single (marque) threads in the current theme forums may be sufficient, with option to make additional sub forums if traffic warrants in future. From a personal viewpoint I restrict myself to the palette of Lego parts (past and present) in order to provide boundaries to the 'puzzle' of finding a solution to a problem/challenge. I can quite appreciate the temptation to utilize logical extensions to a brick family (and have succumbed occasionally) or to 3d print a compact functional solution, but for myself, this seems a slippery path that begs the question where lego stops and scratch build modelling (which I also enjoy) begins. However I am quite happy to use parts by others where the identical TLG brick is not available for sale or is unjustifiably costly in my required quantities.

The type and position of lights will vary depending on what headcode arrangement you have modelled (difficult to see on images) but looks like a block headcode. At different stages in their very long lives class 37 have had: disk head code, split head code and block head code at front with related white lamps. I'm not familiar with that particular loco but https://www.class37.co.uk/fleet.aspx?str_ID=6757 shows D6757 or under TOPS 37057 as having a split headcode with nose end doors. The tail lamps were generally fitted bottom left and right of nose end just outboard of buffers most commonly in a d -shaped shroud though early examples (with disc codes) used a discrete lamp hung on a lamp iron. https://www.cornwallrailwaysociety.org.uk/latest-input--news--old-pictures-etc/27th-october-2022 bottom of page for rear view! While a single off centre red light is most common certain trains would combine red and white tail lamps and engineering trains often use flashing lights

Thanks for all your suggestions and help, have found a solution that works for me! Copied Brickstore inventory (complete with drawer locations!) and my model parts list onto a spreadsheet and performed a MATCH() on part number columns of the two lists - bingo - an instant list of quantities (in hand or short) and locations independant of colour - one happy Plumber and actually frighteningly easy in the end!

I think I understand what you are saying but there is no hope of me reproducing it Way over my limited abilities! This sounds more promising, do I need to have a 'pro' membership for this? Thanks for the suggestions guys, I'm going to have a proper play this weekend see if I can make something work!

Thanks for the suggestion, just taken another look at Rebrickable and tried a compare search, unfortunately it still wants to match part colours The other reason RB doesn't work for me is that there doesn't seem to be any means to record where the parts are located/stored ( my aging brain is not up to the task of remembering where any of 4000+ part types are stashed!!), this seems to be a missing feature on most of the popular sites, its a workaround on Brickstore to add the location info as a remark or comment, I only ever found one brick inventory control software that offered this functionality natively but it was obviously a pro product with a price to match and that waaaay was out of my budget I used to use Basebrick which is great but it's part storage location system was not comprehensive enough for my needs and also with my glacially slow broadband/their server speed it was painfully slow to use, it does have a 'compare' function which on the face of it offers what I need (check box to ignore colours) but it seems to return pretty random results for me If I can find a way to convert my inventory Brickstore file to a CSV file I guess I'll have to dust off my spreadsheet (lack of)skills and query that way, though I can't help thinking I'm missing something obvious here!

I have a large project on the go and build sections in Studio, not being the sharpest tool in the box I often make daft mistakes in Studio which just don't work in real bricks, so I design in Studio then build IRL to check, then modify the Studio model with any alterations needed (often multiple cycles) These 'check builds can be done with any bricks I already have regardless of colour so I can make alterations before making BL orders that turn out un-needed I recently spent some considerable time and effort to catalogue all my parts into a Brickstore database along with their locations in a new storage system. The idea of the database was that I would down/upload the Studio model parts list into Brickstore and compare the uploaded model list with parts in main inventory to show if I have the parts needed in any colour and to have the locations (comments and remarks). So tried this for first time today and it seems that Brickstore is not capable of this colour agnostic manoeuvre It seems that if a field is not in the 'Edit/Copy Values...' dialogue then its value MUST be a match. I can get parts quantities on hand and quantities short for order but only if all fields of the part record match i.e. colour (as well as status, condition etc). It seems my only option is to make a copy of my inventory and set both files with all parts colour N/A gives me locations for picking but no quantities on hand/needed which I would have to note down as picking or run a separate data merge from start. So is it me? I'm not very IT literate so am hoping I've missed something obvious? I imagined many people would check build in colour vomit before committing to large BL orders and therefore do something akin to what I am trying? Assuming Brickstore cannot do this for me is there another way? Can it be done in Bricklink? In conjunction with BL? I'm not a seller but I do have a 'closed' store as it seems to be the only way to obtain a key for BL/BS synchronisation.

Another spear reference? maybe my humor is lost in translation?

Thank you for a very interesting read, while I'm a sucker for BR modernisation era locos I've never been an L-gauger so this book gave me a great insight, thanks for your hard work It's a little ironic that you point out that Holgers prior book about the PF era should have been released just as Lego decided to can the product line given the rife speculation regarding PU

It has brick built headlights - what's not to like??

What a coincidence to happen across this topic today! Just been discussing this with my family this weekend, I lost my little brother four years ago, he and I amassed quite a collection between us in the seventies and early eighties and he left his share to my young nephew my sisters kid (confirmed bachelor my bruv!) Roll on four years and the sets which were being stored at my parents place ( secured out of my reach) needed a new home as they are downsizing, sis had never mentioned the sets to her son as he was too young at the time but turned nine this week, cue him being offered the sets to play with: The ungrateful little tyke made some very uncomplimentary remarks about his late uncles penchant for babies toys and turned up his nose - I almost kissed him - roll on the screen obsessed generation !!! My bike panniers, tank bag and a large rucksack are currently stuffed with sets, all on their way home with me and SHMBO (most of the time) has been put on notice that I will not be available for chores the rest of this month As regards the future of my newly enlarged collection, my Wife knows that the stuff has worth and where to best sell it if she needs the funds at that time but since Lego runs a close second behind the dog for time spent ignoring her, she's more likely to burn the lot

Hardware - software - doesn't really matter which bit is incompatible, the point is it was all made/marketed to look the same with the same (new) connector but motor/hub combinations were a minefield of incompatibility, control+was (albeit subtle difference) not the same as PU and my limited perception of the proliferation of different incompatible softwares in the 'robotics' sets was mind boggling, all of which was seemingly undocumented for years by Lego or hidden behind the high paywall of the Education theme , I would not agree that situation was anything close to perfect! I have no skin in the game regards complex control, not my area of interest ( in spite of, or maybe because of, a career in process control for heavy industry), I have plenty of 9v and PF hardware, am quite happy to buy more from third parties and am quite able to design and fabricate dumb motor packages in any form I might want, just makes me giggle how Lego thought they were going to keep up half a dozen different control programming environments in the crazy world of smart phones and tablets etc without it becoming all consuming but a bit sad for those who do enjoy the 'robotics' type product because PU hardware seems to be gone and the software for the earlier systems seems to be being withdrawn (not just unsupported) and I guess PU apps will follow in medium term I do get that the real hardcore users will do there own thing but then one has to ask why bother with the lego aspect at all? Since this is all getting somewhat off topic I'm gonna shut up now and wait to see what '27 brings us

Thanks for the info and the link - my bad - never owned one (8878) and only ever seen it described as rechargeable and assumed was NiCad or metal hydride like an 88000 with rechargeable AAA cells - every day a school day To clarify the general thrust of my suggestion, I meant a battery box of high capacity and high current capability as seen in RC world since afaik a frequent complaint/observation re PF is the battery box is current limiting which in today's world is a design choice at the power levels /loads we are discussing More generally, we agree that almost all the negative aspects of the PF system could be solved by updating with mature off shelf components/tech, why they didn't??? Anyone's guess! I reckon it's bitten them on the big behind though and played into the hands of the third party generic PF manufacturers

All a very interesting debate but I think it misses the point, Lego have had a solution to this dilemma for decades by running basic motors for lego modellers and the 'education' theme hardware and software for those inclined in that direction Dumb motors and battery boxes for those who just want simple motorisation of mechanical function eg 9V, PF Programmable motors/controllers and sensors for those more interested in automation/coding RCX,NXT,Mindstorms, Spike,Prime or whatever the latest fad is The intermediate ground for RC vehicle models seems to be comprehensively covered by some excellent third party products already The issue I see with PU was that it attempted (unsuccessfully) to standardise hardware across all use cases and forces screens and coding onto the masses that have no interest in this aspect and object to needing a smart device Compound this with the rat race (huge resource) to keep up with (maintain compatibility/functionality) the ultra consumerism that smart phones embody, the lack of timely/adequate documentation, and the (relative) high cost hardware and I think it was always doomed in current form My suggestion is that PF concept should be updated to offer Lipo battery boxes (as well as traditional replaceable cell type), radio (not BT) receivers based on standard RC technology that can offer longer distance control, proportional control of the PF servo (maybe make the servo continuously proportional rather than just 7 steps) via either a basic Lego control or function with third party RC world controllers for those that want more facility It seems to me that all the above is mature tech sold at consumer price and availability meaning it could be accomplished with off the shelf hardware/designs packaged in a Lego housing with ease! As far as a new family of the 'robotics' coding/programmable hardware goes I can't really comment byond saying that I suspect the answer lies in a similar pattern of adopting currently circulating technology that already does what people want, I have words like Ardiuno and Raspberry Pi floating in my mind :-)

The torque convertor in an auto box is extremely poor at transferring energy into the engine from the wheels (it is after all been designed to maximise efficiency in the other direction) as a result there is very little engine braking in an automatic which increases the necessity to use brakes under all driving conditions