C4Group::SearchNextEntry would waste lots of cycles looking up file
attributes that were never inspected afterwards. Since all we want is
the file size, and we already get that for free from FindFirstFile and
FindNextFile, store it with the directory iterator instead of querying
it at every iteration.
This reduces load times on my machine by almost half, tested across
several different scenarios.
Our hardware-based skinning doesn't work on certain Intel graphics
devices. Fall back to software skinning on GPUs that return an OpenGL
3.1 context even though we explicitly request a 3.2 one.
Might fix#1459, #1689.
The hammer will now only construct definitions that have the callback "IsHammerBuidable". This will exclude all C4D_Structure objects that are not buildings and can't be build in a meaningful way.
Also, with the carry heavy branch I want to test adhoc built lorries (lorries as construction sites). Sven suggested this.
So it turns out that the fix stops the engine from crashing, but it
still doesn't seem to generate valid code - Aul emits an internal error
at runtime.
The problems here were:
- the pickaxe component list returned [[Metal, 1], [Wood, 1]] instead of [[Wood, 1], [Metal, 1]]. This may be a result of the new component system with proplists; probably the components are sorted alphabetically now
The problems here were:
- the foundry cannot take 400 water from ice if it has a fill limit
- the pump cannot pump anything into the object if it has no fill limit
This is debatable. Let's see how this feels ingame and revert it in case we don't like it.
I like it because I think it gives valuable feedback to the players (and thus can reduce frustration coming from unnecessary actions). But it might also feel like a bug to players.
You could put e.g. tools into the barrel using the interaction menu. This would lead to a script error later, when the barrel did Contents()->GetLiquidType().
PS: And the RejectStack function is part of a private internal interface. I made that clear so the next one does not have to look it up again.
- The new code works with my router while libupnp didn't. :)
- There are some unexplainable crashes in libupnp: #1640
- Using miniupnpc seems to be less complex than libupnp.
- Apparently, miniupnpc also works on Windows, so we may be able to use
it for all platforms.
Disadvantage: UPnP queries aren't asynchronous anymore, but they seem to
be pretty fast (< 1 s).
It could happen that the objects were cleared (after evaluation screen / on section change) but a particle list would remain that would still point to an object (and would then access it).
I am not exactly sure how that could happen, because objects should clear their particle lists on removal (and thus shouldn't really need a ClearPointers).
There is a tiny chance that this points to another bug somewhere in the object removal - that's just a random guess though.
Anyway, this should fix the infamous Knüppeln crash.
Declaring a local variable inside any function works the same way as
declaring it in top-level scope, which gets a bit weird if done inside a
function inside a constant proplist, but is at least consistent.
Thanks to Flinti for reporting this.
On High-DPI displays, the mouse cursor is very tiny. We'll probably want
some high-resolution cursor graphics at some point, but the current ones
scale good enough.
David Dormagen