I updated to the latest version of cafu, but now for some reason my mod doesn't load.
The -svGame Duel command loads up into the menu. I see the Duel Map, which is only in the Duel path, but when I load it up, although it loads up the correct map, I get an error at
HUD_main.cgui:125 - Bad Argument #1 to get:("Frags") variable frags is unknown.
This tells me straight away this is loading the script code from the DeathMatch path, as that is your code. My line 125 is updated to make use of my Score component and looks like this:
local kills = gui.Entity:GetComponent("Score"):get("Kills")
To confirm the game was running deathmatch instead of duel, I moved the DeathMatch folder, and the game crashed with a Microsoft error reporting box. once I tried to load past the menu.
It seems to be loading everything except for the scripts from the correct path. Is there any hard defined link to the script folder anywhere in the code?
I must advise this is also a brand new issue, it wasn't in the build I downloaded on the 28th August, but is in this latest build.
Edit-- I found the problem, the GUI path is hardcoded in the HumanPlayer file. I didn't notice it previously, as I had worked in the deathmatch folder before swapping over to duel, so the code was the same in both branches.. I am now completely independent, or at least, haven't found any other dependency issues yet
I would suggest not communicating directly with the GUI through a component.cpp file, as it makes the engine very inflexible if you want to be able to run more than one game from the same base code.
I also noticed a lot of non-dynamic paths in the .cgui files etc, it may be worth looking at a pathing system which automatically inserts the -svGame parameter that is passed to it, so the engine always goes to the right script files
thanks for your report!
Are you referring to the paths in
Ca3DE/Server/ServerWorld.cpp? These are indeed a problem, and must be fixed.
Or also anywhere else?
I think there should be a rule of no game paths hardcoded in the c++ side of the game, as it breaks flexibility.
I'm currently looking into the Prefabs related code and will get back to this as soon as the Prefabs are working, but in order to make sure that things don't get forgotten, I've filed these tickets:
Btw., a side question: Are you using the global variable
Mapanywhere in your scripts?
This is the Lua "alter-ego" of the root entity of a map, that is, in the Map Editor it's the topmost entity as shown in the Entity Hierarchy (if you rename it there, the global variable will be renamed as well).
I'm asking because I'm considering to make it
localto the related
.centfile, analogously to GUIs in
.cguifiles, as this would also help with implementing Prefabs.
The same topmost entity would then be obtained by a call to
world:GetRootEntity()(this method does not exist yet, I'll implement it soon) or to
some_entity:[url=http://docs.cafu.de/lua/classGameSys_1_1EntityT.html#ad44896acc43a83ea569e9775ef261946]GetRoot()[/url](which already exists).
As a quick question, what command would I use to search for all game entities with a specified component?
Ok, that's good, will proceed.SoulRider wrote:I am not using a call to the Map global variable currently.
You could implement it in Lua yourself, i.e. useAs a quick question, what command would I use to search for all game entities with a specified component?
EntityT:GetComponents()to search the entity for the desired component, then use
But indeed, this would make a nice built-in, C++ implemented method as well, which does not yet exist. Do you want to give it a try (it would probably be a nice exercise), or do you want me to look into it?
The new method would be added in the
Libs/GameSys/Entity.*ppfiles, and, matching the existing (Lua) find methods, probably be named
As we want to support recursive searching, it is probably helpful to implement this method in C++, too. The Lua methods
FindByID()are similarly made, calling their C++ counterparts in the same files, and can serve as an example.
A specialty of the new
FindByComponent()would be the fact that it doesn't return one, but possibly many entities. That is, in C++ an
ArrayTwould be used, and in Lua a table. You can see how this works in the (otherwise unrelated)
GetChildren()methods, for which there are C++ and Lua versions, too.
This should give you a good start, but just let me know if I should tell you more.
I'll come back to it in a couple of weeks if you haven't got there first
I have just started a new job, so my programming time is very limited at the moment. I would be very grateful if you could add this for me, so I could be more efficient with my limited time
I've compiled the new file, but yet to start testing it. Will probably not be for a few days though. I'll keep you updated
Users browsing this forum: No registered users and 1 guest