ReleaseNotes:Planimate 4.16 Release Notes

From Planimate Knowledge Base
Jump to: navigation, search

Release notes, bug fixes and misc enhancements to Planimate 4.16


  • have sped up splitter operation by caching item tupling information
  • added label list dump to model info
  • have enhanced debug log:
  • the log start time now determines when debugging logs start
  • new options enabling logging of every switch decision and message send/ returns


  • control paste (bulk replace) of portals has been enhanced

now any messages coming into or going out of the replaced regions will be retained - that is any message entries within the region connected to a dispatcher outside the region or vica versa will remain associated as well as there is a corresponding object
This also applies to wormhole entries and exits


  • crash bug when browsing message entry references fixed (had broke in



  • I've reversed the internal searching code in the train graph view.

This will make viewing of huge tables (> 50000 rows) possible now as long as the train ids tend to increase over time
(cyclics should not be affected)

  • Dial display/update when stat is hidden

I've rewritten the way dial's track their visibility, so please report any new problems with the appearance (or lack of) of dials.

  • I now cache item<->table tuple mappings. Models using them heavily will run faster


  • broadcast description code buffer fixed (could cause crash when browsing references


  • attribute reference browser has been enhanced


  • Copying and pasting or control pasting a portal also copies all of the stats on its screen and pastes them relative to the new portal
  • Added new system attributes enabling a subsystem to access its owning portals graphics without having to use a label list
  • unreferenced label lists, broadcasts,, item classes and label subsets and multilabels are purged on model copy/paste to avoid proliferating junk between models
  • item attribute name browser only shows item attributes for flows which enter the change object concerned
  • New button in tuple edit dialog generates a report of the item classes and the attributes<->table columns which will be tupled


  • crawling portal fix

Portals with customised states no longer attempt to retain their X-CENTRE when their image changes at end of run.... the bottom left corner is always the pivot for scaling and state changing.
This means *IF* the model moves a portal during a run to keep it centred as it gets scaled, it will also want to re-initialise its position at the start of the run as the portal may have shifted when the model restarted (and its image changed/rescaled).
If just the state/scale is changed, the position will be retained, unlike


  • fix bug with directed broadcast error appearing
  • was looking up wrong list with the index
  • added portal "show in background" option

portal image can be shown BEHIND dials/stats so nice overlay effects can be performed
I dont background the mouse focus yet so you wont be able to get to your dials without moving the image


fixes portal/stat offset introduced when a panel is resized containing portals which have the "Move Views With Portal" option on


A directed broadcast sent to a panel without at least 1 listener is considered an error


fixes queue rectangle bug introduced in O


[new file format]

Completes update started in


Portals with customised state images and the "retain state" option on will retain their image and any scale factor when the model is stopped and also when the model is saved/reloaded
Combined with the use of BMPs for state icons, this makes Portals very powerful visualisation objects.
When a portal reverts to a different icon upon stopping or starting the model (due to re-initialisation of its state and scaling) it is kept centred automatically, unlike when the user changes its state which pivots on the bottom left point. This looks less disconerting.


  • have made changes to object (eg portal) positioning. This MAY impact current models if the size of the icons positioned differed from the default "idle" state icon

1. All position set and get commands work with the CENTRE of the object - midx, midy. This has not changed from before
2. Changing an objects icon will use the lower left corner of the object as the pivot for the new image. The MidX/MidY is now updated - if the new icon is of a different size, the centre has changed.
This is different from before where object x/y were not being updated to reflect the new centre
3. Changing the xscale/yscale of an object uses the lower left corner as a pivot. Its simple to keep the object centred by saving and restoring the midx (and/or midy) as I do in the SHIPVIEW demo

  • Have added new object attributes
  • Width and Height give the current object's image dimensions (with scale applied)
  • STATE enables user defined portal states to be read and written remotely without having to do it within the subsystem. I used this to simplify the SHIPVIEW model

STATE also enables the state of any other object to be read, dont rely on this yet as it will probably be changed/enhanced!

  • cleaned up path management code
  • empty path databases no longer created for screens during object scanning (and old ones will get purged next time you go to flow mode)
  • internal splitter path management cleaned up
  • added code to scan paths for objects to provide info to the routine editor
  • removed crop of all object y co-ords to 8 - this was used to guarantee old DOS objects weren't under the DOS status bar and is obsolete (they had to be offset-left to hide them before)
  • changed object image scaling to update object bounding box


Bug fixes
Two very similar looking but different bugs in the animation manager

  • an animation manager bug which caused items leaving a queue to interfere with each other and leave behind crud, exposed if the items were wider than standard (and hence overlapped) (I was not maintaining z-order properly when moving single items)
  • an animation manager bug which caused objects which changed their icon size to interfere with nearby icons in queues (I was not hiding the foreground icons properly)

When planimate is executing a while/iterate/search it occasionally polls the system for stop events. This poll was being done every 20000 iterations, i've dropped it to every 6000.
To stop such an operation, you must press <ESC> (dont hold it), make sure Planimate is foreground - the mouse is not polled.
A slow system may take a few minutes to get to it but it eventually will ask whether you want to stop the run.


Bug fixes

  • icon palette crash with null icon selection fixed
  • import filter

Now treats quoted empty field the same as an unquoted empty field


  • Billboard Table (option when creating a table)

Enables viewing of a number of attributes for a number of portals in a tabular manner, the columns are the attributes, the rows are the objects

  • in the Table-Edit -> Table menu associate a new billboard with an object label list

(initially it binds to all model objects, I suggest you crete a sub label list with the objects you want to view)

  • an "_object" column maps each row to a specific object
  • Create columns with names of the attributes you wish to view. The format will be automatically retrieved from the first row (first object)
  • if the number of rows does not equal the number of entries in the associated label list, the billboard will be automatically regenerated

This means you can sort (during edit) the _object column to your liking and the order will be retained until the associated label list is changed

  • The billboard contents are only active/up to date while the model is actually started. During edit they do not track the portal attributes or formats.
  • if a column has an empty label, it is left un-bound - it does not get mapped to any attributes.
  • DO NOT write to the _object column or any of the bound attribute columns - these parts of the billboard are intended read only and will be enforced as such.
  • Cell stats add now in view menu
  • Cell stats can be added to VLTs, those beyond range of table during run will not update and cannot be edited

During the run, cell stat will remain bound to the same row regardless of any row insertion/deletion (not the case during edit where they attempt to track their original row)


  • bug fix for directed broadcasts


  • reformatted condition list dumps


  • animation fix: set up of item movement vector was incorrect for items animating in block mode
  • properly disable recent list in menubar during model run
  • display option enables optional formatting of attrefs as

p.Attribute instead of pAttribute

  • portal attributes can be defined on-the-fly while editing an attref


  • table driven entry bug fixed: they were not validating against blocked items properly, causing item count mismatch errors


  • increased formatting width for condition attrefs (when shown on "if" etc
  • multi-condition has "Report" button which writes the condition description to a file and opens notepad to view it
  • Routine also now writes "report" to a file opened by notepad All conditions are expanded
  • fixes bug reporting item mismatch which caused a crash due to a badly timed redraw


  • DIRECTED MESSAGE mode in the dispatcher lets you direct a message to a given message entry. You can also direct a message to a portal as long as it contains a message entry called _!message
  • bug fix when loading spatial nets which are exported


  • instance object unblocking optimised
  • no longer have FEC check for duplicate posted events, each object tracks if it has an outstanding unblock event
  • fixed object click handling
  • debug trace enhancements - events selected in the debugging memory currently written to the Planimat.DBG file
  • extra profiling counters added
  • directed broadcast calculation operation

enables a broadcast to be sent to a single subsystem location

  • broadcasting an item no longer loses its carried items



  • I have rewritten the way objects display as the model runs. They now draw through the animation manager (as do items) which means they can be drawn transparently and animated very smoothly. So big transparent portals are now possible.
  • Multi-icon support

The icon system now supports selecting a series of icon images (ICN or BMP) for an item or object. The animation engine will then change the image as the item/object animates, enabling rolling and walking effects as things move.
The icon palette still selects a single icon, you set up an animating icon sequence using a naming convention as follows
<name> <@> <index>
where <name> is the image name, <@> is the "@" symbol and <index> is a 2 digit index starting at 01
For example, the new BMPDEMO model uses:
TRI@01, TRI@02, TRI@03 up to TRI@08
The icons must be consecutively numbered and the first in the sequence (@01) must be selected in the icon palette. The system loads until one fails (in this case TRI@09 would fail) which then sets up an 8 icon sequence.
The images may be of different sizes, but remember their origin is the bottom left corner.
The stepping between images is controlled by new item/object attributes described below

  • New system item & object attributes, icon scaling

As these attributes are intended for run time assignment their settings are not currently saved with the model and in fact cannot be edited directly, only via a calculation.
Item X Scale, Item Y Scale
These enable an item's image to be scaled in the x and y direction. They are specified as a percentage, normally 100. Be wary of large values, you will run out of memory and probably kill win95.
Item Image X Step, Object Image X Step Item Image Y Step, Object Image Y Step Item Image Time Step (ms), Object Image Time Step
These control how stepping through images is performed (for multi-icons)
If X step is non zero, the x co-ordinate divided by the value is used to index an image, the default of 8 changes the image every 8 screen pixels. Likewise for Y (by default this is 0)
The Time Step value uses the system real time clock to step images at a specified time interval (20ms is a good start) so the image will change at a regular interval no matter how fast the item is moving.
Note: Time stepping cannot be used to animate items or objects which are not actually moving. Yet.
= Consolidation of decision and comparison code
Different code was being used to evaluate

  • comparison of values in conditions
  • comparison of values in routine lines
  • comparison of values in a binary search
  • comparison of values for unblocking

This could result in different evaluation if a condition comparison is made vs. a routine line comparison, due to the way round off was being handled. Round off gets introduced when values are computed through any kind of calculation, so a calculation which should yield 15 may in fact yield 14.99999999999999 as far as the system's representation is concerned.
To make reliable value comparison possible, equality testing is now done in a consistent manner, as follows:

  • Values are considered equal if either
  • the magnitude of both is less than 1.0e-12

(an arbitrary "small number" I have chosen)

  • the magnitude of the difference between the 2 values is less than the value with the greatest magnitude scaled by 1.0e-10

This means that there is a fixed 10 digits of precision *in comparisons* made between values, so for example:
10,000,000,000.0 and 10,000,000,000.1 will be considered equal
10,000,000,000.0 and 10,000,000,005.0 will be considered different.
This means that values can be safely compared for equality regardless of their absolute magnitude. The previous approach used a fixed "delta" of 1.0e-12 which meant that comparing 2 very large values became unreliable as the inherent precision of double arithmetic is limited to about 15 digits.
Note that the internal values are still stored in full precision to avoid extra roundoff error being introduced.
Finally, be careful when doing comparisons:

  • Dont assume exact equality unless you are indexing, checking a search result etc.
  • use range bounds to trap values which are computed and may not exactly match what you expect. To check if a bin is empty, check

bin_level <= 0.0

  • If you are comparing a computed bin level to a threshold, dont subtract the two and compare the result against zero, let the system compare the 2 values directly so it will be able to determine an appropriate precision for the comparison.
  • Avoid repeating a comparison,

eg if (a > b) action if (a <= b) action
instead use a select-case (I know else would be nice). I've not noticed failure of this but given the vagaries of floating point you cant be too careful.

  • NEVER EVER repeat a critical comparison if the value has been processed in between, with the assumption that the comparison will turn out the same both times.

eg you make a decision to do something based on raw bin level
you convert the level to a percentage
you then re-check the percentage to determine if you should do the thing you originally decided to do via the raw bin level.
This is just asking for trouble and will wreak havoc if the second decision doesn't fire even though you were convinced it should because the first one fired and you have scaled your decision critera properly.
For a given value do your decision making (eg: threshold check) in one place and store the decision result separately for later stages to use.
In fact, in general you should avoid re-testing something you have already tested, store the test result the first time, use ONE select case to catch the possibilities, etc.

For those that want to know, here is the algorithm I use:
const double COMPARE_MIN_MAG = 1.0e-12; const double COMPARE_PRECIS = 1.0e-10;
// determine greatest magnitude between the 2 values
double v_scale = max(fabs(v1),fabs(v2));
// if both are very small (or 0)
if (v_scale < COMPARE_MIN_MAG) return 0; else { // the difference
double dv = v2 - v1;
// the threshold we assert equivalence at
v_scale = v_scale * COMPARE_PRECIS;
if (dv >= v_scale) // v2 is greater return -1; else if (dv <= -v_scale) // v1 is greater return 1; else return 0; // values close enough to consider equivalent }


To top off the introduction of full colour icons I have completely rewritten the Animation Manager in Planimate. The AM co-ordinates the display of the icons as the model runs. The new manager handles updating of the icons much more efficiently, important since larger icons can now be animated.
The main noticeable change (apart from faster, smoother animation) will be that OBJECTS CAN NOW BE TRANSPARENT. This is made possible since the Animation Manager now manages their images as well.
Also items now flip peoperly
Technical Details (for those interested):
The old AM used to hide and reshow icons very often during repaint, especially when they overlapped. Whilst the user doesn't see this (it happens off screen) it wasted time and poses a problem with bigger icons (which not only take longer to draw but are more likely to overlap).
I've added a mechanism where the Simulation Engine can give the Animation Manager hints about what is happening with the icon, This enables the manager to perform many optimisations as it redraws the icons in their updated positions. The "hints" include:

  • Animate this icon to a new position then hide it (eg: item entering a server)
  • Animate this icon and keep it at front, it will animate again soon (eg: item animating through a string of switches or change objects)
  • Animate icon with others in a block (eg: items on conveyors, roads and tracks)
  • Move this icon to a new position but dont bring it to the front (eg: items shuffling through a queue, repositioning an object)
  • Change the icon of this object, leave it at its current location/z-order (eg: object changing its state)

The manager code performs all these operations whilst

  • maintaining z-order of icons (newer items appear at front) Enables items AND objects to be animated very smoothly even when they overlap with each other.
  • keeping block animating items (eg: items on roads) in front of items in queues etc, objects etc, which they can animate over
  • sorting block animating items by the object they are on (makes overlaps between roads look nice and layered)
  • maintaining backing store integrity (so an item under any other item can move out and not leave any "dirty bits" behind it. Important now very large icons can have transparent parts.

In addition I had to implement re-entrancy management to prevent an internal redraw while animation was underway (eg: window resize) which would otherwise confuse the animation manager.
Let me know how it goes.


After 10 years of living with 16 colour icons, I have FINALLY rewritten the animation handling in the system, so now...

  • iconic objects and items can be rectangular and of *any* size your machine can handle
  • full colour bmps can be animated both as item icons and object icons (using the new "Animate Object" routine operation)
  • The palette browser also shows BMP images (reduced to fit the palette) but they will appear full size when selected
  • the icon editor has been banished... its a separate EXE now. yep it still only handles the 16 colour icons
  • The icon mover now takes the icon editor's place in the menu bar. It can display and move BMPs into folders and DB files.

BMP files

  • can now be selected for object and item icons
  • I support 8 bit and 24 bit BMPs, others should work too
  • Transparency is supported as follows

Any pixels that are "Planimate Grey" which means
RED = GREEN = BLUE = 0xBC (hex) or RED = GREEN = BLUE = 188 (decimal)
will be mapped as transparent... so you can have nice irregularly shaped items (and soon objects during run)
If this causes your "silverware" scans to appear with holes in them (where pixels match the transparent colour) either edit the image to avoid the transparent colour or you can force an image to never be transparent by ENDING its name with a # symbol (the hash)
I dont store in the model whether a particular image is a BMP or ICN (the old 16 colour icons). For any given image name, the system first attempts to load a BMP with that name, following the usual search of the working directory, system directory and _*.DB files therein.
If that fails, it will fall back to looking for a .ICN file. So FOO.BMP will always be loaded in lieu of FOO.ICN, even if you pick FOO.ICN from the palette.
!!!*** VIDEO MODE NOTE ***!!!
To enable arbitrary colour BMP display I've had to abandon palette management. Things will still appear in 256 colour (8 bit colour) mode but it will get ugly as more complex images are used and transparency doesn't work.
So make sure you are running High Colour (16 bit) or True Color (24 bit) if your system can support it. If not and you have a desktop, consider upgrading your video card. If you are stuck with an old notebook, 16 colour icon operation should still be OK.
In making this all possible I've rewritten or modified the following subsystems, please take care particularly with your precious image DBs:

  • DataBase management/saving/updating (to greatly speed up updates when the big BMPs are moved in/out/renamed)
  • File copying routines (used by database)
  • BMP loading / display (though paint BMPs should work as before)
  • Item icon draw/animation
  • Planimate Object bounding box / boundary management (so non square objects are possible)
  • Display Object coordinate mapping (fixed the animation trails left when animating while zoomed)
  • The icon palette/pickers/mover & their current directory management
  • Image animation routines (speed up & optimise)
  • PRINTING needs to be tested when stopped and running
  • the icon editor (now stands alone) but I had to rewrite parts of it so I could build it with the new toolkit

ALL of my testing has been under NT4 SP4 so if you experience crashes or strange displays:

  • note your video card type and display mode settings
  • try a different video mode
  • check if you are running out of resources (a real possibility under 95/98 regardless of how much RAM you throw at it)
  • check if you have the latest driver for your video card

This EXE should be file format compatible with


(which of course wont load the BMPs you can now select for object/item icons...)

SOON TO COME:- the original request that inspired this rewrite... run time scalability of portal icons in width and height.

idkbase note 159