Falling actor can continue being in falling state under specific conditions.

Some changes were made in editor sources (looks like GSC didn't use 3DS Max and LightWave at all) so that exporters cannot be compiled.
Need to fix that (just for consistency).

Does anybody want to work on exporters for new 3DS Max versions?

Need to analyze changes made by GSC to make sure it actually can be decoupled.

Examining the stack trace of an error caused by loading a game in the current build, some addresses appear to become corrupted after some Lua-related functions are called.

ex:
the original stack content:
0018B418 048F13C9 ЙSЏ; /RETURN from xrGame.CGameObject::shedule_Update to xrGame.048F13C9

gets modified to:
0018B418 008F13C9 ЙSЏ; /RETURN from xrGame.CGameObject::shedule_Update to xrGame.048F13C9

after the call_member function is called. This appears to be some sort of stack corruption, which will have nasty (and undetermined) effects in code execution. Notice the address change from 048F13C9 to 008F13C9.

This is somewhat related to the ongoing effort to fix #11.

The problem is that IID_ID3D11ShaderReflection guid from Windows SDK is not accepted by d3dcompiler from DirectX SDK.
In future it would be reasonable to get rid of old DirectX SDK and use Windows SDK only.

Would be simpler and cleaner to switch to a tool like Premake instead of just dealing with a VS solution and a lot of vcxproj files.
CMake offers a nice way to deal with third-party dependencies.
Premake makes use of Lua and thus, is a bit simpler (at least, it's what I noticed) than CMake but anyway, the main point of this issue is: determining whether or not we should switch to such a tool.

Pros

• Don't have to bother with a lot of VS-specific files in the repo
• Changes made to the solution / projects are much more readable and noticeable (spotting a change in a clean script is usually simpler than in a messy XML file)
• Users can build the solution and projects for a specific IDE (depends on the tool used)
• Some tools offers a cool way to deal with third-party dependencies (no need to grab each dependency manually, and we could even automate the download process)
• If we ever want to port X-Ray to another platform, using such a tool will avoid spending time on porting the solution / projects files to a different environment

Cons

• Some build tools are more less heavy and we may not be able to pack them in the repo
• All the contributors who are not familiar with such procedures may (depends on the tool itself) need to spend some time to understand how to work with a build automation tool

Build automation tools

• CMake
• GYP
• Ninja Aims to be used with a higher-level build system
• Premake
• SCons
• Valve Project Creator

It looks like AA option (r3_msaa) doesn't work well - sometimes it works, sometimes it doesn't.
Need to find how to reproduce it and fix.

... and add it as a 3rd party library or git submodule.

Per-vertex lighting I believe causes a good deal of problems in XRay. A good example is light bleed through walls and ceilings. Another is easy to see on weapon models, where both sides get lit up at once, or how at certain angles it only lights small parts of the model and not others.

Concerns: performance cost

Thoughts?

P.S. Yes I will commit the actor shadows nitro, I just have been quite busy and I'm still trying to figure out how to use Git Shell.

Is this dead guys? It would be really sad if so. Alundaio has successfully made changes to the source including grass and actor shadow, and FoV command in console.

I think we should have a place other than IRC to discuss engine changes a bit.

The things in "proposed engine changes" that have a * after them are things that I've already done, and most of which I've ported to COP already for a friend. Most of those are weapons related, since I'm focusing on working on a weapon related mod.

Soon I will assign tasks to myself, but it sounds like others are interested in weapons as well. Perhaps we should have a seperate branch for these changes as not everyone will want them?
Things I can't do myself but want to see: Abakan firing 2 shots at 1800rpm, fixed abrupt transition between walking, running animations and then idle anim with grenade launcher attached.

To add to the list of other things I've done, I made it so you can't reload while sprinting.

In terms of a comment Kevin/Loner left in the file, in terms of Gore there is skeleton wallmark code (bullet holes on bodies) partly implemented but commented out in places. Unfortunately my attempts with it so far have not been successful, and it would need to be rewritten entirely for DX10&11 it looks like.

CTD occurs when compiling under Release configuration.

Ideally this shouldn't happen, as we would like to have a debug free binary for releases :)

This occurs during the scheduler's update function call (stack trace in comments).

I managed to compile VS2008 source in debug, after i fixed a vsprintf error.
I made this in zutil.h:
http://pastebin.com/9hYWbVLQ

The compile process is going fine with this fix, but i can't start the game with the new debug binaries:
http://pastebin.com/DTW8uUtm

Did someone managed to compile stuff properly in debug, or did i make a mistake with my fix, which causes this ugly error?

@nitrocaster I am impressed. You are on fire optimizing the engine right now in ai_cleanup! Great work!

I just wanted to say that I looked at your todo list, and there are several of the features you are looking for in the revoculas branch on here, which I have contributed to as well.

It has fixes for the DirectX compiler error (you need to add dxguid.lib to the stdafx.h, it fixes it).
I also fixed blurred R4 font on there, it's in that branch's xrRender/dxFontRender.cpp.

There is also corrected sun path, actor shadows on all renderers, and many other improvements.

On the newest avotishin branch that the revoculas branch is based on, there is also LuaJit 2.0+

You probably already know, just wanted to give you a heads up so you don't reinvent the wheel.

Works on R1.

Should be added as a submodule. See https://github.com/nitrocaster/GameSpy

Apparently USE_SUNMASK in config.h or config_defines.h does not work in DX10&11 (after deleting the shaders_cache of course). I'm pretty sure it works fine in DX9 though.

Anyway, it would be nice if we could get it working properly for 10&11. The error it spits out is the typical "your video card doesn't support this, blah blah blah" shader error.

Cromm Cruac, of Atmosfear 3 fame, also suggested not just to universally get this working without having to modify the shaders each time we want to use it.
That last part I know how to do, I just don't know what causes the issue with 10&11.

... appears and disappears depending on the sun direction. Need more details on how to reproduce.

Hi. Is this still running? Do you actually have the source code for the whole engine? For free use?

Right now vsync is not working, GSC fixed this issue a while ago with their multiplayer patch, i have been looking at some functions like rsConstantFPS which seem to be something in that direction but do not work correctly ingame

How do we go about creating a working executable or set of executables from the source? I'd be intrigued to try out the supposed new grass shadows, and then start looking at making changes of my own.

To all collaborators: please review Proposed engine changes.txt. Add yourself to doc/design/tasks.txt and add tasks you plan to work on.

Normally, the 'color' character should be followed by a space: "! WARNING: ...", "* ...", etc.

When i use xrbinup.cmd, i get an error "cp" is not recognized as an internal or external command. What should I do?

Nitro - are you using Astyle to format code? If so, please share your settings

Defines and typedefs such as BOOL, CONST, UINT and DWORD are used pretty much everywhere in the codebase.
Most of these defines where introduced a long time ago (BOOL was added before bool was thrown into C++) and now, most of them are meaningless.
Nowadays, every decent compiler should support C++'s fundamental types without any problem.
Of course, DirectX types and some other funky types (HWND, HHOOK and so on) can't be replaced but there's no excuse for more common types I've pointed out earlier.

Pros

• Less error-prone (every Microsoft specific type names are upper case)
• Makes high-level parts of the engine less dependent on MSVC / Windows API
• Improves compile/runtime speed and makes debugging tasks easier (BOOL is a int typedef whereas bool is a true type)
• Syntax highlighting / code readability is slightly improved; GitHub syntax highlighter (and probably many others) don't know about BOOL, HANDLE or DWORD but it does its job perfectly well on the standard types.

Cons

• Nothing. Really, I can't think of any drawbacks.

What to do?

There's nothing hard. We just need to search for these types and replace them by their standard
equivalent.
If you _really_ have to use a non-standard type in a piece of code, it should be better to keep this code 'away (i.e. not in a header nor in the middle of a high-level source file)
To make things easier, here's a table with what should be considered for replacement and their equivalents.

1 - Representation of an integer type for pointer precision

• INT_PTR / LONG_PTR are mapped to a 32-bit signed integer on 32-bits systems and to a 64-bit signed integer on 64-bits systems.
• DWORD_PTR / UINT_PTR are mapped to a 32-bit unsigned integer on 32-bits systems and to a 64-bit unsigned integer on 64-bits systems.

It's clear that the easiest way to do that would be to use cstdint along with the standard types. Feel free to share anything, any ideas about all this.

Alpha transparency works improperly - objects like steelworks and meshes quickly lose details and become invisible when camera moves away (r1 doesn't have this problem).

[Google Translate] I analyzed the source code LuaJit. There's only one slight change. Maybe we should bring this LuaJit project as a separate library compiled dll? This will allow the library to make updates to newer versions.

[Google Translate] last push to ai_cleanup increased the tools to build the version v140. now I must update my version of sdk?

Dedicated server appears to crash when run with Debug configuration. From @nitrocaster the following log output is common:

"ID3DDepthStencilState #%d created"

And may be of use.

When posting debug logs, please use some paste service like pastebin, please.

I'm talking about your ai branch of course.

I realize you're not finished what you want to do it, but all the changes got me excited to try and start engine changes from scratch with your repo as the base.

However, when I tried to compile xrScriptEngine it claims there are several undeclared identifiers, including: m_script_name, m_virtual_machine, and m_active.

Sorry to bother you and thank you for your time.

P.S. If I follow proper coding conventions would it be cool if I took care of a few things on your task list in the form of pull requests?
I could do: blurred text fix for R4; incorrect sun path (you say for R1, but do you want sun path to follow environment config variables as that's what I'm referring to); actor shadow for R2-R4; grass shadows; grass draw distance settings; removal of R1; improve weapon system (new optional animation types, new optional sound types, re-enable zoom and reload dof, add console-controlled manual reloading); I also believe OGSE had a transparent geometry fix so I could look into that too.

If any of that interests you let me know, as since I'm toying with your source in various ways while toying with my own project, I don't mind helping out to the extent that I'm capable (and I'm not anywhere near as terrible about things as I was a long while back when I tried a couple of bad commits to your repo ;) ).

Also, a suggestion: when browsing through ODE a bit I noticed it seems to have some shared code with Nvidia PhysX. Maybe instead of updating ODE to the new version you could use PhysX instead, as that would also easily allow other things such as non-performance draining particle collision, particle shadows, vegetation collision, etc. Just a thought.

One last thing: check out this game development newsletter that was sent out about common causes of stutter and micro-stutter in games and how they can be fixed: http://go.nvidianews.com/Lds0NF00d0sE3OCcD060E0M

Didn't mean to merge into your branch, I was trying to merge my master branch into my ai_cleanup.

I'm still new to using Git, how do I reverse this?

Also consider if it's possible to delete tinyxml (which xrXMLParser is based on) sources and add it as a submodule or 3rd party library.

Plz fix a bug in xrRender/ParticleEffects.cpp in line 546 and xrParticles/particle_actions_collection.cpp in line 1779:
change from if (p_cnt < nWorkers * 20) on if (p_cnt < nWorkers * 64)

I have had two programmers look at this issue and neither could figure out why clouds_texture does not correctly lerp between two different sets of clouds_texture.

For example if I set 9:00 in the config to have one clouds_texture, and I set 10:00 to have a different one, rather than a smooth transition between the two, the second it turns to 10:00 it immediately changes to the new texture, which obviously works terrible.

If at some point you were interested in tackling this, or anyone else that's reading this, I would be really grateful.

please update task list. thx

I would like to have a prebuild version of engine, I'm trying to debug wine nine state tracker code and this would help a lot
Also is there a way to disable bugtrap.dll? It is really inconvenient to debug engnine/wine/mesa while bugtrap.dll hijacks signals

See MgcMath.h.

branch ai_cleanup, please remove links to xrcorestatic.lib from additional dependencies in projects: Maya_Material_2008, Maya_Material_2009. Thx