ReleaseNotes:Planimate 4.25 Release Notes
Release notes, bug fixes and misc enhancements to Planimate 4.25
- Track loops have an option to call the out routine immediately after the train starts to leave. Currently stopped trains only call the out routine after the train completes its exit delay.
- new command line option /MAXIMISE (/MAX is OK) maximises the application window when Planimate is started.
- Have extended the "No Following Trains For 0 Loops" option for track loops
- trains never can block at the loop (if the section they move onto is busy, the run will fail with an error
- the loop in/out routine do not execute
- the loop entry/exit delay have no effect
- the loop gate does not take effect
- loop dwells are not acted on
- Pasting a table view no longer has possibility of pasting outside window area
- Added new label routine operations:
- ReIndex List With Values
This takes a label list and two columns. It changes the index values of the labels identified in the first column with the corresponding index values supplied in the second column.
- The index values are validated, if any duplicates or invalid original index values are passed, the model is stopped with an error
- NO TABLES, ATTRIBUTE OR ITEM label values are updated with the new index values. This means any existing label references of a particular index will be invalidated if the index values are changed with this operation. This is provided to assist in building new lists.
- Create Panel Label
This takes an Object Label (which must be for a Portal) and returns the corresponding Panel Label Index for the portal's subsystem. If the portal's subsystem does not have a Panel Label, one is automatically allocated.
(new file format)
- the "Display Bounds" on both column overlay and log driven graphs can now be set at runtime by right clicking on the scroller window, as in edit mode.
- New routine operation enables a column's width to be changed on the fly. You will need to force a repaint to see the change.
[new file version]
- Table views have a new option enabling the space reserved for row labels to be fixed at a constant value. If the value is set non zero, then space for "n" characters is always used.
This overrides the table parameter which enables the "minimum row label" space to be specified. Unlike this option, the view specific parameter will always be used even if the labels are longer than the space allowed for
[new file version]
- have changed Application Panels so its now OK to put a zero delay single capacity multiserver into an app panel, useful for debugging.
= now allow zero delay single capacity multiservers in application panels =
A multiserver with a pauseable 0 time delay and "road view" on by default can be added from the bottom right icon in the object palette when within an application panel.
- new Broadcast option on table views enables a broadcast to be sent after the user sorts the table view by clicking on it and selecting "Sort"
This lets the modeller know the user's preferred sort order for the table.
The broadcast is sent with the following attributes:
_sort1 _sort2 _sort3 _sort4
Each attribute is the column number (starting at 1) or 0. If the reverse sort order was selected, the attribute is the -ve column number.
- BUGFIX - model created portals (dynamically created) have their associated views properly positioned. Previous versions would offset the views.
- If a broadcast is sent when an attribute view is clicked, it now will set the following item attributes if they ecist
"_previous" -> set to the previous value of the attribute "_current" -> set to the value of the attribute after the edit
- Have fixed a double redraw bug which caused popup panels to not display viewports contained in them properly
- Loop "roads" is now an attref so it can be changed (changing while the track has trains on it will probably cause problems)
- Loops have an option now which prevents following trains being allowed when the loop capacity is 0 (no side roads)
- Planimate TCP sockets change:
A failed server connection now puts up a dialog and retries automatically every 2 seconds. The user can "cancel" (forcing the model to stop) or "ignore" which continues the run even though the broadcast failed over the network.
The response of the system will be a little slow, I'm not using multiple threads yet so the system may be trapped in a network call for a few seconds.
- === DLL Calling for routines now implemented ===
This version of Planimate now enables a user supplied DLL file to be called from within Planimate as a routine executes. This can greatly speed up complex mathematical operations.
EG: On my PII-400, a CROSS multiply of a 1000x10 table with a 10x1000 table (yielding a 1000x1000 output table and involving 10 million multiply and accumulate operations took 2 seconds, including item animate time.
DLL's can only be called if they conform to the Planimate DLL API, which is now available for download. A simple matrix utility DLL is provided as a sample for developers. You will need a C++ compiler capable of producing a Win32 DLL to develop using the API. You dont need to know how to call/load a DLL (Planimate does that) and my example DLL provides a calling framework to put your code/algorithms into.
The API means Planimate can interrogate the DLL's available routines and their parameter requirements, hopefully minimising GPFs due to memory allocation issues.
Key features of the Planimate DLL calling mechanism:
- A named function in a DLL can be called from a line in a change object routine
- DLLs can contain a number of these callable functions (called routines)
- Multiple attributes and tables can be passed as parameters to each routine in a DLL.
- Multiple attributes and tables can be returned from the DLL
- All Planimate data types are passed to/from the DLL as double precision numbers. If a DLL is receiving what should be integer values, care should be taken in converting the doubles to integers to avoid round off issues - never trunc() in this case!
- DLLs also return an integer "result" value. This can be used to convey call success, error numbers, as defined by the DLL author.
- table parameters can be entire table references, single rows or columns or block references (starting at the top left to the end of the table)
- Where a DLL expects a table for a parameter, Planimate can handle passing tables, rows, columns and sub-blocks as parameters. To the DLL, it appears as a table.
- Planimate will automatically dynamically allocate space for returned tables according to the following rules:
Returning into a table:
- If the table has no rows or columns, it will be allocated to fit the table the DLL returns. The columns will be unformatted and unlabelled.
- If the table contains columns but no rows, the columns will be retained and enough rows added to fit the table the DLL returns. The column count must match or a model error is reported.
- If the table contains data, its rows and columns must match the table returned by the DLL otherwise a model error is reported
Returning into a row reference:
- The DLL must only be returning 1 row and the column count must match
Returning into a column reference:
- The DLL must only be returning 1 column and the row count must match
Returning into a block reference:
- If the Top Left Cell of the block reference is NOT (1,1) then Planimate will place as much data as it can into the table without ever complaining. If the DLL's table has too many rows/columns, the extra ones are ignored. If it doesn't have enough rows/columns, the existing values in the table receiving the data are left intact.
- DLLs which return no outputs apart from the result code are callable during lookahead, otherwise they must be called in routines that are "only during move" to avoid possible lookahead error messages.
This means that a DLL call can be part of a "look ahead" operation (eg: very complex movement logic) with the movement result/decision coming back to Planimate via the DLL result code.
- tables are passed to the DLL "by copy" and the DLL returns data to Planimate in the same way. This means the same table can provide data to a DLL as the one receiving the result without any consistency issues.
- The default font (until a previous model is loaded) has been set to Arial, since this font will by default scale as its a truetype font.
Let me know if the defaults for new models cause a problem. This change should not affect loading existing models.
- histogram bar no longer gets drawn if point is to left of window margin (due to scrolling)
- attribute view hide bug fixed
- scale/offset option implemented for cell and block selections in the table editor
- new switches act as item guides by default
- Object/Attribute/Cell/Table/Graphical views can by dynamically shown/hidden using a control attribute and a repaint, as for paint objects.
Implementing proper hiding involved changing the way the views are hidden, to avoid grey boxes being left on the screen during the next redraw. Let me know if the change cause other display side effects.
- merging model fix - broadcast label indicies properly updated where a broadcast is merged with an existing bc of the name name
- now support icons being assigned "NULL" icon at a change object. Previously this did not hide the icons causing very strange animation behaviour
- Run code has been fixed to properly schedule animation updates after a run-restart dispatcher takes control of restarting the engine.
Previously animation updates did not occur until after the model was paused.
- Fixed a bug in
introduced when I did a global rename of some source code names, a token in the file loader also got renamed. This caused models containing any Log Driven graphs not to load.
If you have created/edited a model with
and ADDED any Log Driven Graph views, you will have to do a find/replace on the MDL file and change the text "LogDrivenStat" to "GraphPlotStat", otherwise your model will not load.
This will only affect you if you added a log driven graph in
. Older models/exes are OK in this regard.
- Copy spatial link function enables template spatial links to be copied which is useful for creating spatial link-pipes. The "Copy From" specifies a spatial link object which has been preconfigued with the required visualisation options.
- RGB table view redraws much quicker due to an optimised grid draw routine. Modifying indiviual cells will still result in slow redrawing due to the call overhead so its a good idea to not have the RGB view visible while its source data is being updated, or to use a separate working table and then table-copy the data into the view's table.
- Have reworked the x/y scale handling code for graphs. This will now enable x axis scales to contain labels from a label list
- Objects can be renamed to a name with different case without the platform complaining
- drag cursor enhancements and speedup to horizontal time scroller
- Note on "X Scale Interval" parameter
This sets the resolution of the horizontal scroller's x scale. By default Planimate choses a reasonable value but this scale parameter enables it to be overriden. If you use a very small value and the data has a large time range (eg 2 seconds with 2 weeks of data) the display and behaviour of the time scroller will be VERY VERY SLOW.
- Interactive Overlay graphs now support sending broadcasts when points on the graph are clicked and dragged.
- fixes pauseable 0 delay event handling which was rewritten but broken in 4.25 so I could handle event updates for pipes more efficiently.
- new system broadcast "_dataset_loaded" is sent to the model when a dataset load completes
4.25 [new file version]
Spatial Link Pipe View
Have implemented a new option for spatial links which makes them display like pipes without the complicated attribute handling of using pipes.
The basic idea is that the spatial link gets divided into a number of sections. Each section can have its colour set as an item moves through the pipe. In addition to the section colours, separate "activity animation" can occue for non-idle sections, to graphically illustrate material flow. Since multiple items can exist in a spatial link, multiple coloured "bands" can simultaneously animate down the "pipe".
In the options of a spatial link, turn on "Pipe Display Mode"
The Edit menu will now contain 2 new entries:
Pipe Display Settings
This contains constant pipe parameters such as width, section count, and activity update settings. This menu also appears for standard pipes.
This enables 3 dynamic attributes to be defined for the spatial link pipe:
The colour each section of the pipe will be set to as the item moves through it
The activity animation colour (used for the entire pipe) to use
The activity speed and direction, eg: 1 is forward, 0 is stoppped, -2 is reverse double speed etc.
These parameters are looked up whenever an item enters the spatial link, moves between sections of the pipe or leaves the spatial link. A section gets its colour set at the instant the item leaves it.
By dynamically changing these parameters as the item moves therough the pipe, some very interesting effects are possible.
Of all the parameters, the section count is the most important. IT determines how many graphical bins the pipe will be split into. The more bins, the smoother the animation but the more FEC events will be scheduled as the item moves through the spatial link, slowing the model down. This slowdown occurs if the pipe is visible or not.
- Pipe objects editing menu has been slightly rearranged, to enable more common code to be shared between the pipe and the spatial link
- The animation manager has been enhanced to enable items to animate over pipe animation with reduced garbage left behind. This should only affect pipes, report any graphical anomolies.
idkbase note 149