Vampire package error

After updating CGE I get this error when I try to run from Lazarus.
This package cannot be found.
Compiling from CGE editor works fine (though lot of warnings).

Install the package from castle-engine\src\vampyre_imaginglib\src\Packages\VampyreImagingPackageExt.lpk - However, I must agree that this is counterintuitive :smiley:

Ok, I tried but it still does not work.
Shouldn’it be installed automatically with castle base?

still does not work.

What exactly doesn’t work? It throws some error message? Now a new one or a different one? I see you didn’t install the second package (it was asking if you want to install it too, but you seem to have answered “no” - though you should “yes”)

Shouldn’it be installed automatically with castle base?

I don’t think it’s straightfowrard if it isn’t available in Lazarus installation. Especially as CGE requires a specific version of this package, at least for now

Ok, I got it installed but now I get a range of other errors that I hadn’t before. :woozy_face:

Looks strange, try build clean maybe some leftovers from previous versions

Thanks. Ok, I just did that but it did not help, I get the same screen as above.

  1. it better to paste text not pictures

  2. it is better among other reasons for text quotes provide for instant select-and-google-for-quote

  3. according to Google, abundancy of WSRegisterXXXX errors is - at least for LCL application for MS Windows - a telltale sign of Interfaces unit missing from the project main file’s (program, *.LPR or *.DPR) uses clause.

I am not sure if you use Windows, or if non-LCL Castle applications would suffer the same, but try adding Interfaces into the beginning of the LPR-file uses list.

As for missing Vampyre… packages: see More integration with Vampyre Imaging Library, used by default with both FPC and Delphi – Castle Game Engine .

  1. You can install the
src/vampyre_imaginglib/src/Packages/VampyreImaginePackage.lpk
src/vampyre_imaginglib/src/Packages/VampyreImaginePackageExt.lpk

as Eugene pointed out.

  1. But I would actually recommend using “Preferences → FPC and Lazarus → Register Lazarus Packages” button in CGE editor. After making sure that the Lazarus configured / detected by CGE editor is the one you actually use.

    This follows our manual, Install | Manual | Castle Game Engine .

    And it is also a more future-proof method. Whatever changes we ever make to packages and their dependencies, that button “Preferences → FPC and Lazarus → Register Lazarus Packages” is the easiest option to just register all necessary packages with Lazarus.

As for WSRegisterXXXX errors:

Please submit a testcase, i.e. a project that compiles that allows us to reproduce the problem. I do not experience it myself – just tested on Windows too, with latest CGE, both TCastleWindow-based and TCastleControl-based examples compile fine in Lazarus.

My blind guess is that your project mixes LCL with TCastleWindow, and it is causing problems. You can possibly workaround it by using Interfaces unit, but in the end you should not do this. The program code you show refers to TCastleWindow, so you should not use anything from LCL. See Use engine inside Lazarus form using TCastleControl | Manual | Castle Game Engine .

But definitely it will be best if you submit a reproducible testcase, then we can debug definitely what is the problem :slight_smile:

Personally i hit the interfaces problem when converting simple Delphi/VCL applicaiton to FPC/LCL

It turned out the Lazarus’s project converter notoriously forgets to add the unit.

Point is - and it is my blind guess - could this somehow happen if GCE project was developed in Delphi first and only then somehow converted to Lazarus? Or would it even then only be possible if mixing self-hosted-CGE with LCL ?

Depends on how you would convert Delphi application to Lazarus.

The point is most likely irrelevant for this case, anyway. @Carring is active on this forum long ago before we got Delphi compatibility, he’s developing his application in FPC/Lazarus from a long time. He was compiling it successfully in the past using FPC/Lazarus, as numerous threads on this forum show :slight_smile:

We don’t really have enough information to speculate here. We need a reproducible testcase showing the problem to tell what is the reason/solution for these WSRegisterXXXX problems.

Meanwhile I googled around for this and I found

https://www.askingbox.com/question/lazarus-program-without-gui-many-wsregister-errors

Then I added ‘Interfaces’ in the file and everything is fine again.
I think it strange as it only happened after last CGE update?

It’s indeed strange and it should not be needed. No CGE examples need it. CGE in fact (when you use TCastleWindow) should not need any unit from LCL. I realize you solved the problem on your side, but I’d still like to debug it more:) To make sure we know what was the cause, and we can address it on CGE side if necessary.

  1. Try CGE examples. Like examples/animations/play_animation

  2. Submit a test case to reproduce, ideally a stripped down version of your project that still requires Interfaces unit on your side.

The examples work fine.

Then I outcommented the implementation part of my project code and it gave no errors, so there probably is something in the implementation part that causes the error (that wasn’t before the last CGE update).
So I think I will have to outcomment every procedure in the implementation part one by one to find out where the code is that causes this error.
That will be a lot of trying things out but I guess it is for the benefit of CGE. :wink:

There isn’t that much in implementation section that could trigger this. Look at uses clause – what do you use there?

If you have some other unit depending on LCL (like LazarusPackageIntf that you mentioned earlier) then that is definitely the culprit. You should not use LazarusPackageIntf (it is only for code that registers property editors in LCL – even most TCastleControl applications should not need it).

I did not add lazarusPackageIntf and I don’t see it in the unit list, so how can I remove it from the project?

@Carring Dialogs unit on your screenshot is from LCL. This is most likely the reason of your troubles. It defines some LCL message-boxes, like ShowMessage, that you likely used.

In CGE, you can use MessageOK from CastleMessages or Window.MessageOK.

The fact that it compiled previously means that probably

  1. Your project had LCL in dependecies. (See “Project Inspector” → “Required Packages”). Remove it, then such usage will not even compile, so you’ll be safe.

  2. You probably never compiled using F9 from CGE editor? As CGE editor doesn’t pass paths to LCL, so compilation likely didn’t work there. It will work once you remove LCL units from usage.

As for LazarusPackageIntf – sorry, I was referring to your earlier message, that I see you deleted since. If you don’t use it, then cool. (If you want to check, just use “Find in Files” in your project or any other grep-like tool to search for LazarusPackageIntf).

Yes, I removed it and now everything compiles without error. :slight_smile:

Yes, sometimes I use F9 from CGE. And my project runs fine with it (without the WSRegister errors).
The reason I mostly use F9 from Lazarus is that CGE editor does not show exactly what is wrong when there is a compiling error if I change code.

1 Like