presumably, if you can get things working with SDK3, it will work with SDK2.

?? < lol: what happens if you put 4x? in a row <<<
> but will both run happily on the same system? can the compiler look to one
or other libraries, or will it be able to find what it needs if it is all there? or
will there be conflicts and foul-ups?
agreed, there may not be much sense in producing sems for v 1.0x at this
stage, and there are *a lot of modules* to check out already- but there
may be reasons why new ones migt be wanted/needed eg: making own
sem with multiples, for example.
ie: at some 'power user' level, we should be able to drop into coding c++ mode
whenever we need a special function for something, right? in an ideal world. ..
but we may yet be able to find an easier way! (wishful thinking...)
one reason i can think of is that GUI/subcontrol sems have a different background
colour in 1.01x and rigid application of direction rules, and i find it quite nice to
do GUIBools stuff in. SDK2 modules...?work? in 1.1, and a-ha, now i've found out
what 'build code skeleton' is for: easier conversion of sem from sdk2 to sdk3
(nb: i would like, for instance, to be able to make sems of larger containers with
lots of multiples, in GUI-side sem, such as arrays of boolsplitter, or mutliples of
macro-prefabs where you might have 7 or 8 sems for a simple operation)
also perhaps: if someone had both running and produced a new sdk3 sem, it might
be relatively feasible to run it again in sdk2 with minor modifications to produce the
same sem in sdk2 version? just an idea...layman's thinking!