Progress Report?

[scott]

Hi Carsten, its been mighty quiet around here, got any progress reports you can give us?

[Carsten]

Hi Scott,

well, you're right, it's been a bit quiet lately, but that was because I developed the unfortunate habit to "blog" in the #ca3de IRC channel. Status report blogs should of course go into the forum instead, and this is what I'll return to in the future!

Besides an additional lot of real-life issues which temporarily slowed things down, the expected release date of the upcoming 7.10 version is mid to end October, November 1st the latest. Release candidates will be uploaded beginning in early October though.

In general, it turned out that the main goal of introducing scripting support implied an important by-goal: The enhancement of the Ca3DE collision detection system. Each of the goals in turn has many facets, and it took me time to address them one-by-one to achieve a combined progress.

Here is a list of some of the recent detail aspects:

• Have you seen http://www.ca3d-engine.de/phpBB2/viewtopic.php?t=365 ? This one mentions one of the many crucial sub-aspects of the upcoming scripting support.
• The ancient, clumsy ladder climbing code has been revised in order have it use the updated collision detection code, which should be the common and uniform underlying basis for all physics calculations. The old ladder climbing behavior has been largely maintained, except for
  • turning your back to the ladder loses the grip and you fall down, and
  • getting an initial grip on a downwards ladder whose top is near you toes is pretty hard now.
  I'll address these issues later (i.e. post-release).
• Collision detection against static detail models (in fact, against arbitrary entities) is working now: Entities that are "solid" (they have their own brushes and patches) are now treated like mini-maps, that is their collision behavior is as expected. The key idea is that for any other entity (e.g. static detail models) that has no collision brushes etc. assigned, you can explicitly assign a collision model now.
  Currently, this collision model must be another (very small) .cmap file. Creating such a file for a static detail model is only necessary once and works as follows:
  • Open CaWE and select the File --> New... menu.
  • Place a static_detail_model entity into the map, and assign it your desired model so that the model is shown in the 3D view. This model only serves for your visual reference for size and spatial orientation, it has no other purpose.
  • Make sure the entity origin is aligned with the world origin at (0, 0, 0).
  • Now create arbitrary brushes at your choice that approcimate the collision surface of your model. Usually a single brush is enough.
    For example, I tried this with the Models/Static/television.ase and Models/Static/WeldTank_blue.mdl models, and each only took me a single cubic brush.
  • Save this "mini-map" near the model file, e.g. at Models/Static/television.cmap. This file is now the collision model. (Or in fact, the solid primitives of its worldspawn entity are. Everything else, including the static_detail_model entity placed in the second step above, will be ignored.)
  Later, when you're working in your actual map, just
  • select the static_detail_model entity in there that you want to assign the new collision model to, and press ALT+RETURN to open the Properties dialog,
  • add a new property key "collisionModel" with value "Models/Static/television.cmap", and
  • save and recompile the map.
  • Done!
• Currently, I'm still working on "triggers", i.e. volumetric entities that provide another means besides 3D world GUIs to call script functions. This is very important, because 3D world GUIs and triggers are in fact the main and only means to cause a script function to run (unless you call it from the console).
• The final missing piece is the ability for "entity binding". Entity binding means to bind the spatial location of an entity A to another entity B, so that when B moves or rotates, A moves or rotates accordingly. This is important whenever e.g. a lift, vehicle, moving platform etc. moves and objects in or on should go with it.
  This is a bit tricky because you can both bind per script command, e.g.

  Code: Select all

  barrel:BindTo(wagon);

  but moving players must also establish binding automatically whenever they e.g. jump onto a platform. Moreover, a platform that moves and hits the player must also establish a binding to the player to pick him up.

Ok, that's the current progress, and I must say that I like it very well. I'll also build plenty of examples of the new features into the TechDemo map, and this is essentially why the release date is only in mid to end October.

[scott]

Wow Carsten thats great news! I like the sound of the model collision system. It sounds to me like you have gone this route for a future physics system.

The entity binding sounds good, will we be able to bind an entity to something like a characters bones like in Doom3?

[Carsten]

Well, a physics system will sit "on top" of the updated collision system, so that's just another of the facets that play a role.

The binding will eventually also allow to bind to individual bones; I realize that that is a very important feature. However, my next intermediate goal is to make lifts and moving platforms work, and therefore the initial binding implementation will begin with the simpler method of binding-to-entire-entity. Once that works, adding more features like binding-to-individual-bone can be added relatively easily.

[Carsten]

Hi all,

just wanted to let you folks know that I've thoroughly revised the Ca3DE in-game console support last week.

It's still Lua-based of course, but there have been many technical enhancements, the most important of which is in the access metamethods to the ConVars table.

This means that ConVars can now be used even more like normal Lua values, especially you can do e.g. LightsNum=3 even if a ConVar with that name does not (yet) exist. This is very important during initialization, where the new code processes a config file named config.lua that takes any default setup desired.
See the new text The Command Console (near the bottom) for additional information, but please note that that text refers to the upcoming 7.11 version of Ca3DE, which has not been released at the time of this writing.

The above change also means that the value of a ConVar remains available to the Console even after the end of the lifetime of the ConVar. For example, if you modified a ConVar that is used in a Renderer DLL, then unload the DLL and reload another all in the same Ca3DE.exe instance, then the ConVar in the subsequently loaded renderer with the same name than in the previous one will be initialized with the last value in the previous renderer.

It's all really simple, just wait for the new release to see the details.
This especially solves Scott's problem with a default value for the cl_maxLights ConVar, but being able to finally configure Ca3DE via a proper config file also solves many other issues for many people (including me ).

Also note that all variables and functions are now in the global namespace, that is, you can write help() instead of the cumbersome cf.help() and cl_maxLights=200 instead of cv.cl_maxLights=200, which nobody ever got right on the first try anyway.

Finally, also the TAB key for auto-completion will work a lot better with the next release: It will actually complete with the longest common prefix that is possible in the current situation, before printing all available completions when it is pressed next. This is the behaviour most folks are used to from Linux shells.

In summary, the Ca3DE Command Console will work a lot better with the upcoming release. At startup, Ca3DE will run a config script in the context of the Console. This config script can set default values for any console variables, but in fact, it can run a complete, full-featured, user-provided Lua program.

[Carsten]

After some additional code clean-up, here is the result. More formally than above, but also more clearly:

Code: Select all

D:\Dev\Projects>svn log -r head
------------------------------------------------------------------------
r338 | Carsten | 2007-10-31 12:15:16 +0100 (Mi, 31 Okt 2007) | 35 lines

Engine / General:
Thoroughly revised the "console command manager", which was renamed to "console interpreter"
in the course of the changes.

a) Console variables now "overlay" regular Lua values. That is, when they are created during engine init,
   their default value is taken from the Lua value with the same name (if such a value exists),
   then the Lua value is nil'ed and thus "replaced" or "overlayed" by the console variable.
   (This is still implemented with Luas table-access metamethods of course.)
   When the console variable is unregistered again, the Lua value with the same name and last value of the
   convar is restored. See the big comment in Libs\ConsoleCommands\ConCommandManImpl.hpp for more details.
   Note that this change was a prerequisite for the next item b).

b) The "config.lua" file is now loaded and processed early during engine init in the context of the
   console interpreter. This makes setting default values and much more possible.
   (In fact, *arbitrary* Lua programs can now be run in "config.lua" - just *think* of the possibilities,
    as for example loading more config from the users "home" directory, running *any* wrapper application,
    showing *any* setup/config dialogs of *any* complexity, etc.)
   This was actually the main and initial goal of this revision.

c) Console variables and functions are now not in their own exclusive namespaces/tables "cv." and "cf."
   any more, but in the global space "_G". Therefore, we now write for example help() instead of cf.help()
   and cl_maxLights=20 instead of cv.cl_maxLights=20. This is obviously much better.

d) The ConsoleInterpreterI::NameCompletion() method was replaced by the new LineCompletion() method,
   which is a lot more universal and powerful and even has a binding to Lua.
   As a consequence, the "TAB line-completion" feature has not only become a lot better and useful,
   it also remains largely under the control of the Console.cgui script rather than being hardcoded!

e) Misc:
   - Minor bug-fix in DeathMatch ladder code.
   - Minor fix in BoundingBox3T<T> code.
   - The "blueMaskedTest" material definition now declares "meta_editorImage noEditor", too.
   - Fixed the member initialization order in the copy constructor of the CGameConfig class of CaWE.


------------------------------------------------------------------------