Any resolution above 640x480 results in irrecoverable system crash.

System info:
OS: Windows 7 x64
CPU: Intel i5-750 (4 x 2.7GHz)
GPU: AMD Radeon HD 6870 (Driver 12.6 non-beta copy)
RAM: 8GB
CC: B27-R2 (unmodded)

---

CC starts fine and runs for approximately 20s-1m before the display locks up, then turns black, then displays a corrupted image and locks up completely. Computer is unresponsive to input (mouse or keyboard). Computer doesn't respond to a single press of the power button or reset button and an emergency shut-down has to be used.

I've tried unlabelled, VGA, SVGA and HDMI resolutions some fail regularly (can't display resolution message, reverts to 640x480) others result in the aforementioned crash.

What is your screen resolution?

Where are you defining .proneState?

I'm not sure if this is a bug, but it is a serious gameplay flaw.

There's no way to surrender a site.

It's only really a problem when my base is too defended for them to get in, but I don't have enough funds to crush their brain, causing a stalemate that can last hours.

It's being defined in Create(self) by the HumanAI.lua that's been dofile'd into the same script body, which is the only way I could bring the HumanAI.lua into the movement script. When the issues with "require" have been fixed this will be a non-issue, ofc.

I.E., it should be non-nil... I think? I'm a little fuzzy about whether dofile would keep 'self' accessible to both scripts or whether they're just two scripts running in sequence but don't share memory. If the latter... that would be useful to know

Anyhow, I did this because I did not ever see self.proneState == AHuman.PRONE ever return true in an Update() loop, so I tried that.

My guess is that it never tracks AHuman.PRONE unless it's under AI control, and that's not cool; all control states need to be visible at all times, or it's very difficult to write good control scripting via Lua. I finally worked around the issue, but only after I realized that you simply cannot manually define an AHuman's RotAngles without causing huge sim problems under certain circumstances.

Also, there is no purely visual particle effect on this engine, which is major issue in terms of performance. Can this be added?

We're talking MOPixels that don't have an Atom defined and are just delivery devices for Glows, basically.

While I'm talking about Glows, can we please have multiplicative and additive glow rendering behavior via a switch? Smoke needs to use multiplicative to be convincing, whereas fire usually uses additive.

When a shot is generated by a HDFirearm, any Lua attached to said object running on Create() or Update() doesn't apply until the next frame.

I got my CC from the humble store wiget thing so i have a few questions (Keep in mind im new to CC) the techion for me only have the bullpup rifle and techion all purpose robots/brain. enemys almost never spawn in endless skrimish defence and fullscreen does not work will all this be fixed if i move CC out of my program files?

EDIT: i recently got the latest CC and got the techion wepons and i messed up and thought the imperatus were the techion CC fullscreen still wont work though and enemys still take a long time to spawn in endless skimrish defence

1920x1080 but I play windowed because fullscreen does the same crash as resolution change.

all of my problems are fixed except the full screen issue i guess i can play windowed

Additive blending is really working in a strange way.

This, for example:

Should be a very dark, almost-translucent smoke puff, barely raising the color levels of whatever it's up against.

Instead it's reaching near-white levels unless I force the EffectStartStrength way, way, way down, and the color values simply aren't right.

It doesn't matter if I only have one on the screen and nothing is overdrawing, I still get near-white values. Without seeing how Glow was written, I'm really, really confused; isn't this just a quad with basic additive blending and a simple shader interpreting the RGB values as translucency after clipping near-black texels?

Anyhow, I'd like to see this fixed and have a multiplicative Glow switch; you need both additive and multiplicative to do a lot of FX stuff convincingly and I'm trying to get rid of as many Sprites as possible, since they are pretty laggy.

I don't really know if this is something that should fit in bug report, but it appears this build compared to b26 has a really big delay and is generally more "laggy" than b26?

Short spinup / spindown sounds have issues; they start but don't stop on the timer, and continue to loop.

i find that its much faster, infact... Too fast.

While AHumans may use:


ACrabs may not use:
Because those properties aren't defined.

It'd be nice to not have turrets sitting around without their turrets, eating up MOIDs, and that's the easiest fix.

Just a nitpick, but just after starting a game, when all the techs are minmised,
clicking maximise on one of them will maximise all the other techs instead.

Annoying as hell...