Making / distributing mods (a few questions)

Get help with installing and running the Cafu Engine here. This forum is also for general questions and discussion of all aspects regarding the Cafu Engine.
Post Reply
jellypox
Posts:7
Joined:2016-05-19, 20:34
Making / distributing mods (a few questions)

Post by jellypox » 2016-05-28, 20:42

Hey, I've got a couple of questions for Carsten on topics I couldn't find a straight answer for in the documentation.

1. First of all, I noticed that when you open cafu.exe, it automatically loads up Deathmatch. How do you change what game the engine loads up when you open the executable? Is there a Lua script file somewhere that points it to the Deathmatch directory?

2. If I were to distribute a Cafu mod as a standalone game, would renaming cafu.exe to the name of my game pose any problems, or is the filename referenced by other programs and scripts?

3. I noticed that when I set the resolution to my native (1920x1080), it just scaled and stretched the main menu GUI. Is there a simple way to code a main menu GUI that scales in a more elegant way using only scripting? To give an example of such a solution in very loose pseudocode:

Code: Select all

if (aspect ratio = 16:9)
button1.graphic = NewGameStretched.png
I think that's all my questions for now. Thanks in advance!
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: Making / distributing mods (a few questions)

Post by Carsten » 2016-05-29, 14:27

Hi jellypox,
jellypox wrote: 1. First of all, I noticed that when you open cafu.exe, it automatically loads up Deathmatch. How do you change what game the engine loads up when you open the executable? Is there a Lua script file somewhere that points it to the Deathmatch directory?
You can change the game via a command line parameter:

Code: Select all

> ...\Cafu.exe -svGame Test
Also try:

Code: Select all

> ...\Cafu.exe --help
jellypox wrote: 2. If I were to distribute a Cafu mod as a standalone game, would renaming cafu.exe to the name of my game pose any problems, or is the filename referenced by other programs and scripts?
No problems (that I'm aware of).
jellypox wrote: 3. I noticed that when I set the resolution to my native (1920x1080), it just scaled and stretched the main menu GUI. Is there a simple way to code a main menu GUI that scales in a more elegant way using only scripting? To give an example of such a solution in very loose pseudocode:

Code: Select all

if (aspect ratio = 16:9)
button1.graphic = NewGameStretched.png
This unfortunately is one of our yet unresolved problems, see ticket #112 for details.
Best regards,
Carsten
jellypox
Posts:7
Joined:2016-05-19, 20:34

Re: Making / distributing mods (a few questions)

Post by jellypox » 2016-05-31, 00:19

Thank you for your reply!
Carsten wrote:This unfortunately is one of our yet unresolved problems, see ticket #112 for details.
Well, from the sounds of that ticket, implementing that GUI system overhaul would be quite an undertaking. I guess I'll just have to work around it, tailoring my menu graphics to look alright on HD monitors. :)

There's one more thing I'm wondering about, now. I'm interested in coding levels with rooms and hallways that change when you're not looking, so the player could leave a room, and when he comes back, the room he was just in has vanished, and a completely different room is there in its place. The easiest way I can think of to accomplish this effect is to place the "dormant" room in an inaccessible point somewhere out of view (probably below the skybox) and put the "active" room in the playing field, and write a scripted event that makes the two rooms trade places. What I'm wondering is (a) could this method easily be implemented with rooms that are comprised of multiple brush objects, e.g. using selection groups? (b) could this be done with rooms composed of static detail models, or are they immovable, as the name implies? and (c) is there a more elegant way of doing this? Ideally, a room would not exist at any point in the map while dormant, so that when room A replaces room B, room B is literally removed from the scene. However, I'm not sure whether there's any way to do this within the Cafu engine, so moving the dormant room to a position in the map where it can neither be accessed nor viewed might be the only way to achieve this effect.

I'm sure most of these questions are answered somewhere in the documentation, but I am still learning the basics of this engine, so I thought I'd ask in advanced, just so I could plan ahead. Thanks for your time!
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: Making / distributing mods (a few questions)

Post by Carsten » 2016-05-31, 16:08

jellypox wrote:There's one more thing I'm wondering about, now. I'm interested in coding levels with rooms and hallways that change when you're not looking, so the player could leave a room, and when he comes back, the room he was just in has vanished, and a completely different room is there in its place. The easiest way I can think of to accomplish this effect is to place the "dormant" room in an inaccessible point somewhere out of view (probably below the skybox) and put the "active" room in the playing field, and write a scripted event that makes the two rooms trade places. What I'm wondering is (a) could this method easily be implemented with rooms that are comprised of multiple brush objects, e.g. using selection groups? (b) could this be done with rooms composed of static detail models, or are they immovable, as the name implies? and (c) is there a more elegant way of doing this?
Well, the big question is probably how different the rooms actually are / can be.

If the rooms only differ in the entities that are within them, that is, walls, floors and other brushwork stay the same, the problem can relatively easily be solved. In this case, switching entities on (enable) and off (disable) via a map script can achieve the desired effect (this corresponds to your question (b) above). This is usually how it works in games wherein the player first explores a pristine world, then a catastrophic event happens, and then the player visits the same but now damaged world.

If the rooms are generally allowed to have significantly different brushwork (question (a) above), things are more complicated. Our preprocessing (PVS, Radiosity lighting) is actually not well prepared for dynamic changes to the world geometry, and at this time, I guess that only tricks (that the player doesn't notice) can be used to implement this. You have already described one such trick, namely to swap pre-made rooms that are within the same map. (I don't think that literal removal or simple hiding doesn't play a role here, as the player wouldn't notice any difference.) Another trick that is probably easier to implement is teleportation, also done in a way such that the player never notices that a teleportation has happened.

I'm sure most of these questions are answered somewhere in the documentation, but I am still learning the basics of this engine, so I thought I'd ask in advanced, just so I could plan ahead. Thanks for your time!
You're welcome to post and ask! This forum exists for getting questions answered (and yours aren't covered in the docs anyway), so please feel free to ask whatever you need help with! :up:
Best regards,
Carsten
jellypox
Posts:7
Joined:2016-05-19, 20:34

Re: Making / distributing mods (a few questions)

Post by jellypox » 2016-06-21, 23:47

Thanks a million for your help! A couple more questions have occurred to me. First, how does Cafu know what to do when you first load up the game? Does it automatically load up the appropriately named files in the /GUIs/MainMenu folder, no matter what the game? Secondly, does Cafu use a conservative PVS algorithm? I'm interested in modifying the engine at some point in the future, so I'm wondering if additional occlusion culling might be helpful. I know real-time culling for dynamic objects would be helpful.
User avatar
Carsten
Site Admin
Posts:2170
Joined:2004-08-19, 13:46
Location:Germany
Contact:

Re: Making / distributing mods (a few questions)

Post by Carsten » 2016-06-23, 14:32

Hi jellypox,

the game and (default) world that is loaded on program start can be given at the command line, run

Code: Select all

cafu.exe --help
for details (-svGame and -svWorld parameters). The defaults for these parameters are hardcoded, but easily changed in the source code.

The game's root folder with the game assets is determined from the game and world names and is something like Games/myGame/. At least the top level directories inside Games/myGame/ are, at this time, hardcoded, e.g. Maps/, Materials/, Scripts/, Worlds/.

The PVS is conservative, inspired by Seth Teller's work "Visibility Computations in Densely Occluded Polyhedral Environments". Our algorithm is a bit different however, using portal clipping that I found easier to implement.
You can see its effects in wireframe mode, see this post on how to activate it. (Be prepared for some blind flight, though: F1 toggles the console on and off, forceRM() turns wireframe mode off again.)

The existing PVS algorithm works very well, but is not much help in large, open landscapes such as the outdoor terrain in the TechDemo. This is a yet unresolved problem in Cafu.
Best regards,
Carsten
Post Reply

Who is online

Users browsing this forum: No registered users and 32 guests