LSL modules not always found

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create LSLProject
2. create a folder inside project
3. create scripts and modules, use modules
create another project, put subfolders in, throw some modules you want to use 
in and make that projetct a reference 

What is the expected output? What do you see instead?
at least LSLFore should reliablely find and use modules in the same dir as the 
script using the module and go for subfolders too to get modules
Instead I get error signs where my $import line is, stating module could not be 
found
Also when I move a used and found module out the same folder script is in, 
script.lsl creations goes off/ script.lsl tab vanishes - but no error sign at 
import-statement line -
instead getting an error in error log, stating script.lsl not found

What version of the product are you using? On what operating system?
lslforge 0.1.6
Win 7 64 bit
eclipse.buildId=4.3.0.M20130911-1000
java.version=1.6.0_45
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Framework arguments:  -product org.eclipse.epp.package.standard.product

Please provide any additional information below.
Restarting Eclipse "solves" the problem as the module (in same dir) then is 
found at next edit, for modules in referenced projects (and there in root!) 
editing preferences of current project un/rechecking referenced project helps
Also helping is moving/having module at project root as this is the thing 
letting recognize LSLForge the module always

Original issue reported on code.google.com by sl-z...@postman.homeip.net on 14 Jan 2014 at 2:32

[GoogleCodeExporter]

This bug is introduced in 0.1.5, side effect of 'LSLForge Native Executable
Multiple instances would run, one for each open project. Modified now to share 
a single instance globally.'
It is not good idea because each native process keeps .lslp files and .lslm 
files in each project.
If you want to share the native process among the project, need to switch 
.lslm/.lsl context. It seems not easy.

Original comment by pells...@gmail.com on 15 Mar 2014 at 7:02

[GoogleCodeExporter]

I see... then probably better leave it that way and work around as described - 
also I was told that editing+saving modules helps too.

For me there are more nagging issues, esp. the massive use of brackets. That 
stops using LSLForge optimized scripts in opensim worlds (sometimes use Simona 
to test and debug)

Original comment by sl-z...@postman.homeip.net on 16 Mar 2014 at 11:56