SbuilderX Error on update

#1
I installed the 314 update and now SBuilderX wont run. I get an error about a runtime error. see enclosed screen shot. What did I do wrong? I have a terrain.cfg thats by Orbix that did work, now it doesn't. Also I have a copy of the terrain.cfg that Louis Sinclair worked on, I believe that is the one that Orbix installed.
 
Last edited:
#2
Hi Joe:

I am not familiar with the error you displayed in a screenie over at the "official" SBuilderX314 support forum:

http://www.ptsim.com/forum/viewtopic.php?f=22&t=2310


(linked from Joe's thread at PTSIM):




But I'm wondering if the recommendation by Dick Ludowise (aka "Rhumbaflappy") was able to help solve that issue ?


BTW: I was also intrigued by your reference to a "terrain.cfg that Louis Sinclair worked on" ...being installed by (OrbX ?). :scratchch

May I inquire whether this apparently was as a result of installing:

* OrbX FTX individual airports ?

* OrbX FTX region packs ?

* OrbX FTX Global ?

* OrbX FTX Vector ?


PS: Was the above by any chance also referring to the Louis Sinclair who programs FSDS ?

http://www.abacuspub.com/fs-design-studio-v3-5-download


Thanks in advance for any clarification you might provide in your reply to the above questions. :wave:


I do understand, though, that we have another notable developer with that same first name associated with SBuilderX (programmed by Luís Vieira de Sá): ;)

http://www.fsdeveloper.com/forum/threads/terrain-cfg-fix.3290/


FYI: The modified Terrain.Cfg for FSX developed by Luis Féliz-Tirado and Richard Ludowise is AFAIK, typically substituted by most FSX developers for the FSX default Terrain.Cfg after answering "YES" at a prompt regarding that file ...during installation of SBuilderX.


BTW: There have been reports of scenery content developed using some legacy terrain scenery methods may not render properly (or at all) after installation of OrbX FTX Global, apparently due to further changes made to the above original modified Terrain.Cfg for FSX developed by Luis Féliz-Tirado and Richard Ludowise.

Note that such changes were reportedly made to Terrain.Cfg in a way by which end users were NOT notified of in advance with a prompt, and such changes reportedly altered FSX run time rendering options / priorities ...in a manner NOT otherwise anticipated or wanted. :redflag:



NOTE: Some of the issues related to installing / using the modified Terrain.Cfg for FSX developed by Luis Féliz-Tirado and Richard Ludowise were discussed here:

http://www.fsdeveloper.com/forum/threads/on-manipulating-the-fsx-terrain-cfg-file.6204/


Alternative methods of implementing certain changes to FSX run time terrain rendering via edits to Terrain.Cfg are discussed by the author of FS_Global on Pages 17+18 here:

http://www.fsim.net/files/INSIDE_FSGLOBAL_2010.pdf



As you might know, extended use of the modified Terrain.Cfg for FSX developed by Luis Féliz-Tirado and Richard Ludowise within SBuilderX requires manual edits to several files as discussed here:

http://www.fsdeveloper.com/forum/threads/utility_1-and-2.394520/

http://www.fsdeveloper.com/forum/threads/width-of-roads-in-fsx.427279/


Hope this latter info helps get SBuilderX 64-bit up to full speed for you (after resolving the above issues) ! :)

GaryGB
 
Last edited:
#4
Make sure you run the new SBuilderX.exe and not the old SBuilderX313.exe. Also, I had to delete my old .ini file.
Hello:

Some developers may have custom entries in the SBuilderX version 3.13 *.INI file which they would want to refer to for possible future use with the new 64-bit or 32-bit version 3.14.

So if such users find it necessary to start the new version with a new *.INI file, they would want to make a backup of their old original one (ex: inside a *.ZIP or *.RAR file) first ...before deleting that SBuilderX version 3.13 *.INI file. ;)

GaryGB
 
Last edited:

rhumbaflappy

Moderator
Staff member
Resource contributor
#6
I can get that error popup if I try to run the old x86 SBuilderX (313) with the new x64 DLLs. Make sure you are running the new x64 SBuilderX (314).

Dick
 
#7
I'm still getting it with both the old and the new SBuilderX. The new SBuilderX I have is supposed to be run into the old to update it. I don't know if there is a newer complete install. I was in error with that Terrain.cfg it's By "rumbafloppy" and ( Having a brain fart) the guy that did the Terrain for Orbx (PNW, PF, Etc.) edit: Holger Sandmann.
Is there a complete new installer?
 
#8
Is there a complete new installer?
I've tried every combination of install for the new 64-bit version - either getting the runtime error or the ini file error (even though I did a complete uninstall and verified erasure of all copies of 313).

I'm running Windows 8.1 and made sure the correct .NET version was present.

Is there any possibility of a solely 64-bit full install file being made available?
 

rhumbaflappy

Moderator
Staff member
Resource contributor
#9
Here's the advice I gave Joe at ptsim.com:

At this point, if I were you, I would uninstall SBuilderX with the Windows uninstaller. ( Save any works in progress first, and note the installation folder for reinstallation ).

Then go to the folder where SBuilderX resided, and uninstall the whole folder.

Now you can reinstall a clean copy of SBuilderX313, and give it a go. With all working right, shutdown SBuilderX313.

Using Windows explorer, copy the whole SBuilderX folder and rename the copy as SBuilderX314.

Now you have an original 313, and a copy which you can try to upgrade to 314.

Delete the SBuilder.ini, delete the old SBuilderX exe file before the upgrade, to avoid any confusion.

Follow Luis' instructions on upgrading the copy, then run the new SBuilderX314 program. This should insure you have the right version, with the right DLLs.

If the new version works, you could uninstall the old SBuilderX, or leave it sitting in case there are any more issues with the upgrade.
This seems to have worked well for Joe ( the original poster ).

Luis had decided to use this upgrade patch rather than a full install. You could ask him at ptsim.com for an installer version.

Dick
 
#10
Thanks, Dick. I'll give the "Joe Approach" another shot. Always look on the bright side! It might work if I do it right!! :)

I'll also connect with Luis on PTSim, if possible, and see what he says - failing continuing operator error on the patch install at my end. ;)
 
#12
Haha - yes I knew he was living a life on the ocean wave in the Med but not that long! Nice! :)

Anyway - I GOT IT WORKING (I think). The secret? You must place the copy and then patch install files into the Program Files folder and NOT the Program Files (x86) folder. You probably all already know that already and I missed it earlier. I should also have thought about it before but there it is!

Thanks for all the help, guys. I'll also post to PTSim.
 
#13
iangbusa said:
Also posted on FSDeveloper forum:

I GOT IT WORKING (I think). The secret? You must place the copy and then patch install files into the Program Files folder and NOT the Program Files (x86) folder. You probably all already know that already and I missed it earlier. I should also have thought about it before but there it is! :lol:

Thanks for all the help, guys. I'll also post to PTSim.
GaryGB said:
At PTSIM thread: http://www.ptsim.com/forum/viewtopic.php?f=22&t=2310&p=7919#p7919


IMHO, this raises a question for Luis and Dick:

Are there any legacy 32-bit *.DLLs which are still used for the SBuilderX v3.14 from the original 32-bit installation package which may not work properly if the SBuilderX v3.14 executable is installed and run from C:\Program Files (...for 64-bit installs) rather than Program Files (x86) folder ?

And would I be correct that any such legacy 32-bit *.DLLs still used with the SBuilderX v3.14 executable from the original 32-bit installation package may not work properly regardless of what folder location that SBuilderX v3.14 executable is installed to, and/or from which it is run ?

Thanks for any clarification on this. :)

GaryGB
 
Last edited:

rhumbaflappy

Moderator
Staff member
Resource contributor
#14
Hi Gary.

There are no 32-bit dlls for SBuilderX314. It's a 64-bit program and requires 64-bit dlls. These are included with the update.

Dick
 
#15
Hi Dick:

Thanks for that clarification.

I would respectfully like to suggest that it may prove beneficial for everyone if Luis to were to make an installer package available for distribution as an alternative to / in addition to the new SBX314.zip.

I'd also like to suggest that the distribution packages would be less confusing if Luis were to label the *.ZIP file name with a detailed "build number" such as we have seen in the past with SBuilder as it evolved ...rather than simply being named "SBX314.zip".

Between the Beta and public distribution locations for SBuilderX314 64-bit, we are thus far seeing a single file name of "SBX314.zip" being used, each of which contains either the "SBuilderX.exe" (ONLY), or a combination of "SBuilderX.exe" with various other files.


FYI: I now see that as of today's date, the "SBX314.zip" posted for download at:

http://www.ptsim.com/forum/viewtopic.php?f=29&t=2304

...does include the following folder and files:

Code:
Name___________________________Size________Last Modified_________Attrib___Comment
SBuilderX.exe__________________1,451,008___6/8/2014___3:08:50 AM a________Version: 3.3.3.0
ReadMe.txt_________________________5,055___6/7/2014___9:21:40 PM a
SlimDX.dll_____________________3,718,656___6/7/2014___9:09:56 PM a________64-bit
shapelib.dll_____________________134,144___6/7/2014___9:09:52 PM a________64-bit
FSUIPCClient.dll__________________32,768___6/7/2014___9:09:48 PM a________32-bit
TileServer.dll_____________________7,680___6/7/2014___9:09:36 PM a________64-bit
jmBglLib.dll_____________________253,952___6/7/2014___9:09:06 PM a________32-bit
SBuilderX.exe.config_______________1,505___4/6/2014___3:25:44 AM a

<Tiles> Folder:
Name___________________________Size________Last Modified_________Attrib___Comment
ArcGisServer.dll___________________6,656___6/7/2014___9:11:16 PM a________64-bit
GLS_Server.dll_____________________9,216___6/7/2014___9:11:16 PM a________32-bit
GoogleServer.dll__________________16,384___6/7/2014___9:11:16 PM a________64-bit
IrsGisLab_LandsatServer.dll________5,632___6/7/2014___9:11:16 PM a________32-bit
NokiaMapServer.dll_________________6,144___6/7/2014___9:11:16 PM a________64-bit
NokiaSatelliteServer.dll___________6,144___6/7/2014___9:11:16 PM a________64-bit
OpenStreetMapServer.dll____________5,120___6/7/2014___9:11:16 PM a________64-bit
VirtualEarthServer.dll_____________6,656___6/7/2014___9:11:16 PM a________64-bit
YahooServer.dll____________________6,144___6/7/2014___9:11:16 PM a________64-bit

NOTE: 32-bit versus 64-bit status interpretation by "Quick View Plus" file viewer - by Inso c/o Avantstar
Thanks again for looking into this; and of course many thanks to Luis for providing a 64-bit update ! :)

GaryGB
 
Last edited:
#16
Hi Gary.

There are no 32-bit dlls for SBuilderX314. It's a 64-bit program and requires 64-bit dlls. These are included with the update.

Dick
I think there's a question there for 64-bit OS - doesn't it prevent a 64-bit application from looking for dll's in Program Files (x86)? I'm still really puzzled by this as Dick has the 64-bit application running in the (x86) folder. Ah sweet mystery of life... or Windows. ;)
ian
 

rhumbaflappy

Moderator
Staff member
Resource contributor
#17
Hi Gary.

Your quick View Plus isn't lying... Technically there are a few 32-bit dlls running. I've altered the headers to allow them to compile at runtime as 64-bit. So they are 64-bit, but their code is 32-bit. (That should really confuse everyone).

I used corflags for .Net 4.5 to reset the 32BITREQ flag as 0

That changes the requirement of the IL 'pseudocode' to compile at runtime as 64-bit... even though it was written as 32-bit.

I did this for a few dlls as I did not have the code to rewrite them as 64-bit.

The use of Program Files (x86) is a little foggy to me. It seems more of a hinderance than a help. But remember this is .NET, rather than a native exe. .Net compiles to IL, which is a sort of pseudo-code, and the IL gets recompiled at runtime by the JIT compiler. So truthfully, a .NET program is not an application at all. It's more of a script for the JIT compiler.

I don't know if natively compiled exe's run from the Program Files (x86)... but I suspect the folder is just a folder.

Dick
 
#18
Just quick add to this (I have another mention in another thread and will post on PTSim also).

From what I can see, because I've run under Windows 7.1 and 8.1, the problem appears to be in Windows 8.1 with the shapelib.dll and the way it's used by SBX 314. The same dll functions without a problem with other applications like scenProc under Windows 8.1. Hopefully this will provide a clue regarding what to look for or, at least, a workaround that it runs fine under 7.1.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#19
Hi Dick,

From my experience it doesn't really matter for .NET DLL files if they were compiled as 32 or 64 bit. I never had trouble with them. It seems .NET DLL files follow the EXE that they are loaded from, which I compile as AnyCPU for my tools, so that it works on both 32 and 64 bit. In that case I only needed to find 32 and 64 bit versions of C DLL files used in my tools.
 
Top