Templot Club forums powered for Martin Wynne by XenForo :
  • The Plug Track functions are experimental and still being developed. Some of the earlier pages of this topic are now out-of-date.

    For an updated overview of this project see this topic.   For some practical modelling aspects of using Plug Track see Building 3D Track.

    The assumption is that you have your own machines on which to experiment, or helpful friends with machines. Please do not send Templot files to commercial laser cutting or 3D printing firms while this project is still experimental, because the results are unpredictable and possibly wasteful.

    Some pages of this and other topics include contributions from members who are creating and posting their own CAD designs for 3D printing and laser-cutting. Do not confuse them with Templot's own exported CAD files. All files derived from Templot are © Martin Wynne.
  • The Plug Track functions are experimental and still being developed.

    For an updated overview of this project see this topic.   For some practical modelling aspects of using Plug Track see Building 3D Track.

    The assumption is that you have your own machines on which to experiment, or helpful friends with machines. Please do not send Templot files to commercial laser cutting or 3D printing firms while this project is still experimental, because the results are unpredictable and possibly wasteful.

    Some pages of this and other topics include contributions from members who are creating and posting their own CAD designs for 3D printing and laser-cutting. Do not confuse them with Templot's own exported CAD files. All files derived from Templot are © Martin Wynne.

Templot5 and plug track - progress discussions

Quick reply >
_______________
message ref: 13699
Hi Martin,
I have nearly filled up the print_settings_unit form!
1728429389085.png


Is there a clever way of summing or evaluating the RGB colours so that one can get a measure of light or dark in order to make a decision about what colour (black/white) should be assigned to the font of the colour panel?
R+G+B ranges from 0 to 765, so perhaps a value over 380 could be the tipping point?

Or does each colour have its complement?

I expect the W3C has the answer...

Steve
 
_______________
message ref: 13701
Is there a clever way of summing or evaluating the RGB colours so that one can get a measure of light or dark in order to make a decision about what colour (black/white) should be assigned to the font of the colour panel?
R+G+B ranges from 0 to 765, so perhaps a value over 380 could be the tipping point?

Or does each colour have its complement?
@Steve_Cornford

Hi Steve,

It's tricky, because of different screens and viewing conditions. Google might be your friend.

The user might change the colour to almost anything. Not very likely if printing paper templates to make it very dark or intense, wasting ink. But if for an image export it could be anything.

You could try simply inverting all the colour bits:

Code:
panel.Font.Color:=panel.Color XOR $FFFFFFFF AND $00FFFFFF;

which should guarantee it's at least readable, but when I tried it the result was very muddy. I think it has to be plain black or white.

Simply adding together all 3 values might work, but one bright value might be cancelled out by a dull one. My guess is that if any colour exceeds a threshold value the text needs to be black:

Code:
                                 //////////////////////////////////////////////

                                  function text_from_bgnd_rgb(colour:integer):TColor;

                                  var
                                    red,green,blue:integer;

                                  begin
                                    RESULT:=clWhite;  // init

                                    red:=(colour AND $000000FF);
                                    green:=(colour AND $0000FF00) div $100;
                                    blue:=(colour AND $00FF0000) div $10000;

                                    if (red>128) or (green>128) or (blue>128) then RESULT:=clBlack;
                                  end;
                                  //////////////////////////////////////////////
 
panel.Font.Color:=text_from_bgnd_rgb(panel.Color);

But what the threshold level might be for best results, or whether all 3 should be the same, I have no idea. :unsure:

Over to you. :)

cheers,

Martin.
 
_______________
message ref: 13702
Hi Martin,
Thanks for your font colour suggestion.
After a bit more research & finding this: https://goodcalculators.com/rgb-to-grayscale-conversion-calculator/

I have come up with this:-
Code:
function font_colour_for_rgb_panel(colour:integer):TColor;

var
  red,green,blue:integer;
  average:extended;

begin
  RESULT:=clWhite;  // init

  red:=(colour AND $000000FF);
  green:=(colour AND $0000FF00) div $100;
  blue:=(colour AND $00FF0000) div $10000;

  // calculate Greyscale RGB value using weighted average
  // Y = 0.299 R + 0.587 G + 0.114 B
  average:= (0.299*red+0.587*green+0.114*blue);
  showmessage('sbc average '+FloatToStr(average));
  if average > 100 then RESULT:=clBlack;
end;

which seems to work ok.
Perhaps I should make the 100 a parameter? grey_scale_tide_mark.......

Its funny that when inserting <code>, Pascal is not an option for "Language", or is this yet another thing on the very long TODO list?

Steve
 
_______________
message ref: 13708
Hi Martin,
I have revised the algorithm slightly to give these results with default colours:-
1728469512596.png


Code:
  if (weighted_average>125) or ((green=0) and (weighted_average>100)) then RESULT:=clBlack;

I don't get out much!

Except for now, just about to venture forth for lunch...

Steve
 
_______________
message ref: 13709
Hi Martin,
I think perhaps we might call this Swiss FB fixing type HV (Helvetian).

We can then get going with some code:

Would now be a suitable time for a discussion on a road map for 8 sided chairs?

Looking to the future, I would suggest you consider adding the concept of storing the various tables that are needed in files and providing maintenance frames, rather than hard coding them inside the program source.

When needed or on startup the tables could be loaded into memory as arrays.

Candidates would be:-
Family type (REA, GWR etc)
Rail type
Chair type (2d & 3D master component)
Plinth type (3D component of chair type)
Jaw type (3D component of chair type)
Screw Head (3D component of chair type)
Rail Seat (3D component of chair type)
Key type (3D component of jaw type or chair type?)
Clip type (3D component of chair, or could be treated as a jaw type)

Treat the Chair type as an assembly (as you do now in a way with 4-sided chairs) with the possibility of having:-

2D paras: 4 to 8 sides, 2 to 4 bolt holes
3D paras: 2 to 4 Screw Heads, 1 Plinth, 1 to 4 Rail Seats, 1 to 4 Outer Jaws, 1 to 4 Inner jaws, 1 to 4 Keys
(or for FB rail, 2 to 4 screw heads, 1 Plinth, 1 to 4 Rails Seats, 1 to 4 Outer Clips, 1 to 4 Inner Clips, 0 Keys

Or perhaps I am being too simplistic.

Steve
 
_______________
message ref: 13728
rather than hard coding them inside the program source.
@Steve_Cornford

Hi Steve,

The hard-coding was only ever intended as a temporary lash-up. I wish I could get across to folks just how temporary and experimental every single detail of the current 3D export is. Nothing is fixed. When I started all this chairing stuff 7 years ago I had no idea where it was going or how to do anything. Had I known, there are many things I would have done differently. Not least the 4-sided chair outlines:

index.php


Note the date there. My original intention was simply to get chair outlines showing on the paper templates -- and in the last few weeks you have finally got that working for me -- many thanks for that.

In 2018 I got my first 3D printer, the FDM BIBO. I quickly lashed up some code to generate S1 chairs in 3D so that I could try FDM printing them. It was all hugely disappointing -- I never got more than a length of 4 sleepers in 7mm scale that was anywhere near a success. It was all posted on the old forum (and is still there). For a couple of years afterwards the code was still in Templot but largely forgotten (and accessible only for my own use).

Then in March 2021 I got my first resin printer, the Mars 2 Pro, and resurrected the S1 code to see what could be done with it in 4mm scale with a resin printer instead of FDM. The result amazed me. I remember the moment I threaded the first length of rail through the chairs and realised I had stumbled across a whole new ball game:

https://85a.uk/templot/club/index.php?posts/post-838

That lashed up S1 code is still there, and the original mistake of basing everything on rectangular 4-sided chair outlines is still there too.

Would now be a suitable time for a discussion on a road map for 8 sided chairs?

I need to get that original error fixed before I can get much further. I made a start on it several months ago, but then got distracted by the swap to open-source and Lazarus, and then by COT track. I think I should now get back to it, and then get more of the REA chairs done, at least as far as the slab & bracket chairs and K-crossings.

But I can't make much progress with that if we decide that now is the time to up-end everything and replace the lashed-up temporary code with a properly designed system for the future. That needs a lot of thought and maybe an eventual update to Templot6.

I feel I'm being pushed forward faster than I want to go. Spending so many hours sitting at the computer is not doing my health any good, and getting too many loose ends in play just makes it worse. Already on top of Templot itself I have to get myself from the comfort zone of Delphi5 to the new world order in Lazarus, and try to get my head round GitHub at the same time, all while continuing to explain stuff here and run the forum. One thing at a time, otherwise it's just too much. Changing to a new file-based system for the chair data will have to wait.

cheers,

Martin.
 
_______________
message ref: 13731
Hi Martin,


Would now be a suitable time for a discussion on a road map for 8 sided chairs?

Looking to the future, I would suggest you consider adding the concept of storing the various tables that are needed in files and providing maintenance frames, rather than hard coding them inside the program source.

When needed or on startup the tables could be loaded into memory as arrays.

Candidates would be:-
Family type (REA, GWR etc)
Rail type
Chair type (2d & 3D master component)
Plinth type (3D component of chair type)
Jaw type (3D component of chair type)
Screw Head (3D component of chair type)
Rail Seat (3D component of chair type)
Key type (3D component of jaw type or chair type?)
Clip type (3D component of chair, or could be treated as a jaw type)

Treat the Chair type as an assembly (as you do now in a way with 4-sided chairs) with the possibility of having:-

2D paras: 4 to 8 sides, 2 to 4 bolt holes
3D paras: 2 to 4 Screw Heads, 1 Plinth, 1 to 4 Rail Seats, 1 to 4 Outer Jaws, 1 to 4 Inner jaws, 1 to 4 Keys
(or for FB rail, 2 to 4 screw heads, 1 Plinth, 1 to 4 Rails Seats, 1 to 4 Outer Clips, 1 to 4 Inner Clips, 0 Keys

Or perhaps I am being too simplistic.

Steve
Hi Steve,
That makes sense to me, I think we are at a bit of a crossroads with Plug track. As its clearly growing legs of its own.
If you think about it going forward, there is going to have to be at two main groups
These being bullhead and flat bottom rail. Which is a long away from Martin's original experiments.

As to the two main groups each type has quite a few sub groups, some of BH subsets you have identified above, that can split from there.( please note I am not saying I expect a pleather of information or cad files.) More thinking about having a plan in place we can all work too.

Fundament question, if there is ever going be a scenario where both flat bottom rail and bullhead are going to be intermingled IE early days of FB, where mainlines started to be switched over but secondary or sidings were still older BH sometimes plan track was new FB and the turnouts were still BH. Or somebody modelling heritage railways today. Just two I can think of the top of my head.
The the common Z plane would have to be the top of the rail.

Therefore does it make sense to say now all chairs no matter what type should all be using the top of the rail as the Z plane datum?

Following on the same theme, if your going to have provision for example say REA and any of the regrouping company designs can be intermixed, either by chair on a single project, IE turnout to plain track, what becomes the Z plane datum? Is it the bottom of the rail as it sits on the chair? Which I think it is currently! (but I could be wrong on that)
Or do we make it the top of the rail? logically it should be the top to give the maximum flexibility to the system.
Just my thoughts anyway.
cheers
Phil,
 
_______________
message ref: 13732
I feel I'm being pushed forward faster than I want to go. Spending so many hours sitting at the computer is not doing my health any good, and getting too many loose ends in play just makes it worse. Already on top of Templot itself I have to get myself from the comfort zone of Delphi5 to the new world order in Lazarus, and try to get my head round GitHub at the same time, all while continuing to explain stuff here and run the forum. One thing at a time, otherwise it's just too much. Changing to a new file-based system for the chair data will have to wait.
Hi Martin,
I just read this post after my last reply, please don't think that I was also trying to push you. I was not.

However. I do think we are at, or very close to a point where job sharing is the right way forward. But in order to do that there has to be some sort of plan. So anybody that is interested in can follow the said plan.

Maybe I am out of step here, but what is the problem for example, with you working on 8 sided chairs (which if I understand correctly from previous posts not all the current chairs need to be changed to 8 sided)

Steve could, if he wanted too start to look at a new file based system.

Myself and others could look at cad files for certain types of chairs, (I know there will be some elements of self interest hear). IE a GW fan is unlikely to want to draw Midland, LNWR or any other pre group company before he has done is chosen subject first. Its already already starting happening with all the recent info on the swiss flat bottom rail chairs.
That does not matter, as long as we have a plan to work though it. and at a speed that suits everybody, after all there is no real rush here..
cheers
Phil.
 
_______________
message ref: 13733
Hi Martin,
Changing to a new file-based system for the chair data will have to wait.
ok. The last thing I want is to put you under any more pressure.

As for screen time, it is very easy to get sucked into solving a programming problem and lose track of time, so having spent 50 years of my working life doing just that, I now limit my keyboard time by setting a timer (when I remember).

In retirement my golden rule is:- "Everything takes longer than you think"

try to get my head round GitHub at the same time
Me too.
I tried using my local github folder as my Lazarus RDE folder, but reverted to having them separate as being a safer modus operandi.

I am happier being in control of what is in my Lazarus RDE folder, and only copying the revised files to my local github folder once I am satisfied with the results.

As it seems I am the only one apart from you making changes perhaps we should stick with the concept of raising a WIP flag on here listing the units we are currently working on, as that seemed to work ok, or did you find that too restrictive/prescriptive?

My current WIP:-
export_draw_unit
pdf_laz_unit
print_settings_unit
print_unit

when I am the stage that these are ready to be pulled/pushed, I will let you know before doing anything.

Steve
 
_______________
message ref: 13742
@Steve_Cornford

Thanks Steve.

As it seems I am the only one apart from you making changes perhaps we should stick with the concept of raising a WIP flag on here listing the units we are currently working on, as that seemed to work ok, or did you find that too restrictive/prescriptive?

I felt under pressure to get my WIP finished and released, because I knew you were waiting to access the same files.

I think it would be better if we simply do whatever we want with any of the files, at our leisure. And simply take our WIP flags, if any, as a warning to confer before finally pushing the files to GitHub. Even if we don't confer, Alistair is confident that GitHub won't let us lose anything, and I always have my own separate backups here.

cheers,

Martin.
 
_______________
message ref: 13747
Hi Martin,
I have pushed a commit to my fork (steve cornford) on the online github containing output elements enhancements.
It includes 5 changed files:-
export_draw_unit.pas
pdf_laz_unit.pas
print_settings_unit.lfm
print_settings_unit.pas
print_unit.pas
View of my fork on the online Github:-
1728569336211.png


Is it alright with you if i click on 1 commit ahead of and create a pull request to be merged into your main?

Steve
 
_______________
message ref: 13752
Is it alright with you if i click on 1 commit ahead of and create a pull request to be merged into your main?
@Steve_Cornford

Hi Steve,

Yes, that's fine. I haven't pushed anything since releasing 556a.

Presumably you will be creating a pull request to yourself -- you are now a collaborator. If so, go ahead and accept it/merge it. I'm frequently being invited to create a pull request to myself.

cheers,

Martin.
 
_______________
message ref: 13753
So my new WIP is:-

bg_keeps_unit.lfm
bg_keeps_unit.pas

in order to apply similar enhancement to those in print_settings_unit as suggested by you.
@Steve_Cornford

Thanks Steve.

Bear in mind that applies to the screen only -- so you can use colours such as white and pale yellow which don't make sense for printing on paper.

cheers,

Martin.
 
_______________
message ref: 13756
Hi Martin,
I see that your branch T556B is now showing 5 commits ahead, 4 commits behind Main.

Ignore the fact that it says 4 commits, as I got a bit confused and pulled my one set of updates several times as I thought it had not apllied them.
You should be able to click on the 4 commits behind string and apply them to your T556B branch as there are no conflicts.

Then in your Github desktop you should be able to fetch origin and apply them to your local copy to experience the full panoply of output elements coloured panels :cool:

Steve
 
_______________
message ref: 13759
Hi Martin,
1728599335747.png


On trackpad background options menu there are pairs of hide/show options as radio buttons.

there are other show/hide options as tickboxes.

I have added tickboxes to the expanded right hand side of the background display elements screen for those show/hide pairs that have keyboard combination shortcuts.

I have added tickboxes to the original left-hand side for the two hide/show pairs that do not have keyboard combination shortcuts.

Current state (just cosmetic, no events coding added yet):-
1728603714694.png



Todo:-
template name labels options:
show/hide bricks by colour (menu option does not appear to be working, unless I have misunderstood it)
shapes data... (not needed IMHO)
shapes infill colour
shapes outline colour

plus anything else you can think off or point me towards.

Steve
ttfn
 
_______________
message ref: 13781
@Steve_Cornford

Hi Steve,

I think you have gone a bit awry there.

The bgkeeps dialog is about how background templates are displayed -- which elements are included in them, and now also in what colours, styles, etc. And only background templates.

The questions about whether they are displayed, and whether other features such as background shapes, spacing rings, notch, etc. are displayed, belong in a completely different dialog.

Which doesn't yet exist -- at present it is all done on the menus. When/if it does exist, it needs to be permanently visible, such as a toolbar, so that users can click the options on and off and/or see the applicable keyboard shortcuts without delving into the menu structure to find and display it.

I'm not entirely sure it needs to exist. A simplified trackpad menu might be sufficient. The reason I made so much use of the menus originally (apart from being much easier and quicker to program) is that they don't use up any screen space, and hide themselves after use. Some software is so ringed with toolbars and dialogs that you end up working in the middle of the screen through a keyhole.

cheers,

Martin.
 
_______________
message ref: 13784
Having returned home full of fresh air I have discovered the answer to getting colors to be colours.
1728660619355.png


As LCL uses the Windows widgetset, and having seen an example of the above screen where the legends were in German, I wondered what language my Windows 10 laptop was configured with.

When I first went in to this screen the Windows display language was set to English (United States) and this was the only choice in the drop-down.
So I used the
➕
add a language button to install English (United Kingdom), and after signing out & in I was pleased to see the correct spelling of colours appear :)

1728660814583.png


By the way, I had a boiled 🥚 for breakfast!
Steve
 
_______________
message ref: 13797
Talking of steps, if the sun is shining west of the Severn take a stroll in the fresh air and forget about Templot for a while!
@Steve_Cornford

Hi Steve,

I did - somewhere in Herefordshire this afternoon: :)


buckenhill_1980x1092.jpg


cheers,

Martin.
 
_______________
message ref: 13809
@Steve_Cornford

Hi Steve,

Looking good. (y)

Can we remove "other" from "any other form of output". The trackpad screen isn't output, you have already done the settings dialog for the output.

Also "background display colour options" needs to be "background template display options".

This dialog is about the templates only. The trackpad background needs to be in a separate dialog, such as the pad colour, grid colour, grid spacings, notch, spacing rings, and other program preferences stuff which doesn't change with the track plan.

But added to this background templates dialog could be the group colour, and the highlight colour (templates when clicked).

And possibly some buttons opening bgnd_form (for the background shapes) and brick_form (for the brick colours).

cheers,

Martin.
 
_______________
message ref: 13813
@Steve_Cornford

Hi Steve,

As far as I can remember the fixing peg is hard-coded red in the control template and yellow in the background templates.

The trackpad colour is called paper_colour -- daft name, it's nothing to do with printing on paper.

For the defaults, see in pad_unit the colour schemes:

procedure do_hi_colour_schemes(i:integer);

procedure Tpad_form.preset_schemes_menu_entryClick(Sender: TObject);

procedure Tpad_form.bright_night_scheme_menu_entryClick(Sender: TObject);


...

This stuff hasn't changed for years -- it could do with tidying up. I can't imagine anyone still using a screen set to 8-bit colour depth.

cheers,

Martin.
 
_______________
message ref: 13816
Hi Martin,
As far as I can remember the fixing peg is hard-coded red in the control template and yellow in the background templates.
I found bgkeep_peg_colour:=clBlack, but have now found the procedur pad normal which gives clYellow.

By the way. I only had red berry granola this morning, no boiled 🥚

So my daft question is:-
The trackpad colour is called paper_colour -- daft name, it's nothing to do with printing on paper.
What do you mean by trackpad colour? (now rhetorical, answer might be below:)

On inspecting the colour scheme, i have deduced that you mean:- pad.form.Color == paper_colour == trackpad colour.
Unless I imagined it, I did notice a comment describing this as the colour of the backdrop, which is quite a good descriptive word as far as the screen is concerned.
I have not added a [ backdrop ] colour panel/button yet?
Is it ok if I add a [ backdrop ] colour panel?
I realise that the trackpad (backdrop) is common to background templates and the control template.


I was looking for group colour and highlight colour fields.

Thanks for the hint about the colour schemes.

After a bit of research, assume we use hi_colour (ie 16-bit), then the default are:-


Code:
procedure pad_normal;
                                       // set normal pad colours for Hi-Color...
begin
  paper_colour:=$00E0C0A0;             // a nice grey-blue for the drawing paper.
  grid_colour:=$00C0A080;              // with a darker blue for the screen grid.
  ring_colour:=$008000C0;              // mauve spacing-ring.
  ring_copy_colour:=$00FF0080;         // violet ring copies. // 0.98.a
  page_colour:=$00FF0080;              // and violet for the printer page outlines.
  pad_form.Font.Color:=clNavy;
  preview_form.Font.Color:=clBlack;

  selection_colour:=$000000B0;
  hover_colour:=clWhite;

  rail_colour:=clBlack;                // rail lines in black.
  timber_colour:=$000060A0;            // red-brown timbers (screen colour).
  timber_infill_colour:=$00D8D0B0;     //$00C0D090;     //$00B0D888;     // grey-green infill.

  shapes_colour:=$00205878;            // green-brown 214a  was  $0000FFD0;  lime  212a  was $006000A0;          // dark pink.
  shapes_label_font.Color:=shapes_colour;

  bgkeep_rail_colour:=clBlue;
  bgkeep_timber_colour:=$00608000;         // sage green.
  bgkeep_timberfill_colour:=$00C0C090;
 
  bgkeep_mark_colour:=clBlack;
  bgkeep_peg_colour:=clYellow;

  bgkeep_platform_colour:=$0060C0;   // tan 0.93.a

  guide_colour:=$00C0FFFF;             // cream for track centre-lines, planing marks and f.p. - 0.93.a and platform outlines
  align_colour:=$0000FFE0;             // rad ends (limey yellow).
  trans_colour:=clWhite;               // transition marks.
  joint_colour:=clBlue;                // rail joints in blue.

  info_form.Color:=$00F1E3D7;          // 0.93.a for Windows 7 child borders

  pad_form.bgnd_keeps_font_label.Font.Color:=$000000B0;  // brick red   // 208a was clMaroon;   // bgnd keeps.
  pad_form.pad_timber_font_label.Font.Color:=clBlue;     // timber numbers.

  pad_form.sb_black_white_menu_entry.Click;    // scalebar colours.

  keep_paper_colour:=clWhite;  // 223a   was $00FFF0D8;      // ice blue,  colours for the keep form...
  keep_grid_colour:=clTeal;

  keep_rail_colour:=clBlack;
  keep_mark_colour:=clGray;
  keep_timber_colour:=clMaroon;
end;

So I think the [ group ] colour panel should map to selection_colour and the [ highlight ] colour panel should map to hover_colour.

Steve
edited re peg_colour
 
_______________
message ref: 13819
Last edited:
Hi Martin,
Have now added the coding behind the objects and tested them 🤞
1728756218141.png

I might have misunderstood you regarding brick colours... but when clicked it just shows the brick_form behind the bgkeeps_form as shown here:-
1728756489755.png

I used brick_form.Show; from the pad_unit code. Should it be something other than .Show?
so I added an extra panel in the normal colours section, naming it store brick. Perhaps it could be called store as brick but anyway it mimics the relevant colour button on brick_form (in fact it invokes brick_form.store_marker_colour_button.Click; )

I assume it is just the colour used when storing a brick that is wanted here, rather than all the other 3D button options, so you might be happy with just the store brick colour button, and I could remove the [ brick colours... ] button?

Steve
 
_______________
message ref: 13832
I assume it is just the colour used when storing a brick that is wanted here, rather than all the other 3D button options, so you might be happy with just the store brick colour button, and I could remove the [ brick colours... ] button?
@Steve_Cornford

Hi Steve,

It's the other way round. We want the button but not the "store brick" panel. Or we want neither, because the brick colour is template-specific.

The bgkeeps form is intended to be solely about the appearance of all background templates. Not about any template-specific settings such as the marker colour / brick colour and/or any associated functionality.

Changing the colour on the brick form does other things, for example it changes the default brick colour on the dxf form. And the colour for the brick assemblers on the background shapes. So if we want anything we want a button to open brick form to allow the brick colour for the selected template to be changed there.

The temporary kludge is re-using the template's marker colour as the brick colour, when the template is marked as a brick template. So it has all got a bit confusing. And will only be solved when we finally undo the temporary kludges and have a completely separate function and dialog for the brick assemblers.

If I had known how things were going to pan out I would never have released plug track in its temporary form with so many experimental and temporary kludges, which I made originally just to find out what might be possible. I should have waited another couple of years until all the temporary stuff had been replaced with proper new functions designed for the purpose. It is all coming back to bite me. :(

cheers,

Martin.
 
_______________
message ref: 13833
Hi Martin,
brick_form is the one that is shown when you press the 3D button, so only gives access to the brick colour that is used when storing or exporting bricks, which is equivalent to the one I have added.
I will remove it.

At the moment [ brick colours.. ] performs a brick_form.show which just displays the Experimental 3D form behind the Background details screen.
Perhaps instead [ brick colours... ] should invoke the keep_form which does give access to the brick colours of the existing background templates?

and then invoke show_list_button.Click so that the list of background templates is displayed complete with their brick colours?

Sorry if you feel I am being nit picking.

Steve
edited to add show_list_button.Click
 
_______________
message ref: 13834
Last edited:
If I had known how things were going to pan out I would never have released plug track in its temporary form with so many experimental and temporary kludges, which I made originally just to find out what might be possible. I should have waited another couple of years until all the temporary stuff had been replaced with proper new functions designed for the purpose. It is all coming back to bite me. :(

But think of all the fun you would have missed!

And the enjoyment you have given to a lot of us old duffers!

Steve
 
_______________
message ref: 13835
Sorry if you feel I am being nit picking.
@Steve_Cornford

Hi Steve,

No, I don't feel that. I'm just feeling a bit low about the whole thing today, thinking about how much still needs to be done, and how many more hours I might have committed myself to sitting here.

I'm supposed to be enjoying the computer coding, and I would if I could just follow my own path. This evening I'm playing about with FDM-printed tie-bars, which is a bit of a challenge bearing in mind you dare not get a soldering iron near PLA. But maybe epoxy would be strong enough, if we had a suitable rail fixing? Such as a modified inner jaw. The existing invisible slider design (not yet finished) needs a resin-printed slider, so not helpful for users of COT track who are without a resin printer.

But at the back of my mind I know I should be doing something else, because folks are waiting for it.

The brick form is a complete mess and was never intended to be visible to users. It was just an experimental area for me to dump stuff while I worked on it. Please disregard it completely in what you are doing at present. When we have got it sorted out into something more logical and user-friendly, we can go back and update the other dialogs.

cheers,

Martin.
 
_______________
message ref: 13837
Martin

There is nothing worse than slaving over a job you are not enjoying, I have found you are doing the right and proper thing in doing something else. These spurts of energetic design new areas of design are benefitting us all. The past couple of months Templot has made some massive strides, granted in the larger scales, but 7mm+ scales seemingly have caught up with 4mm.

I am certain something will crop up which will energize your thoughts on obtuse chairs, in the mean time we have a workaround.

Templot 2D is now very much the gold standard in track building, but this did not happen over night. I think there is a lot of experimenting to do with COT track as well as plug track, but it will happen in the coming months and years. We can now produce 7mm turnouts at a quality never seen before, whilst at the same time using a program and building methods most modelers can easily use, that's some feat

Thank you and please enjoy both your programming and experimenting.
 
_______________
message ref: 13845
@Martin Wynne @Steve_Cornford

Hi,

I just created a PR to fix a potentially serious bug that I spotted. I have replaced the marks_list_ptr with a dynamic array of Tmark records.

This removes the Pointer <==> Integer typecasts, that would have been fine with Delphi 5, but will potentially fail miserably with Lazarus on Win64 as Pointers are 64-bit, and integers are only 32-bit.

On a separate note, I would like to continue in this area and remove all the intarray functions, and replace with dynamic arrays, and possibly replace the array of arrays (background marks) with a single array of records.

Alistair.
 
_______________
message ref: 13846
Back
Top