Windows HttpRequestSystem fails on https requests with untrusted connections. The iOS and Android versions currently accept unauthorised https requests

Because of the generic way that RandomInRange is done the highest range value is never going to be selected unless FRand() returns 1. I believe this only occurs in integers because of integer rounding.

i.e.

return in_min + (TValueType)(FRand()*(in_max - in_min));

in_min = 2
in_max = 5
FRand() = 0.999999999f

2 + (int)(0.999999999f_(5 - 2))
2 + (int)(0.999999999f_3)
2 + (int)2.999999997
2 + 2
= 4

Unless FRand produces 1.f, you will never get 5.
While the RandomInRange does not specify that each number has equal chance of being selected I would argue that a number having a lower chance than others of being returned makes it less random (Makes it useless for dice rolls). Either it should be fixed so that integers behave as expected or the function comments should specify that highest number in integers is less likely to be returned.

My work around at the moment is to call this function using floats and round the result.

Inside the Tweener class (ChilliSource/Core/Tweener.h) the get and set methods for the start and end delays the variable names appear to be mixed up. Call me a traditionalist, but when I can SetStartDelay, I expect it to set m_startDelay, not m_endDelay. The opposite happens in SetEndDelay.

I've fixed it in my fork, so you can either pull from that or fix it yourselves (it's two lines).

auto& transform = object->GetTransform();

auto previousPos = CSCore::Vector3(transform.GetWorldPosition());

auto worldTransform = CSCore::Matrix4(transform.GetWorldTransform());
auto result = worldTransform * CSCore::Matrix4::CreateTranslation(CSCore::Vector3(3.0f, 0.0, 0.0));
transform.SetWorldTransform(result);

transform.GetWorldTransform();  // need to call to update transform

CS_ASSERT(transform.GetWorldPosition() != previousPos, "Wrong world position");

Manually set the world matrix for an entity will return wrong when asking Transform::GetWorld...() methods because it return the local values when there is no parent.

Also manually set the world matrix for an entity with a parent will return wrong local values.

Is it really necessary to make a copy of the ChilliSource each new project?
Why not link to the source instead?
It reminds me a traumatic experience with cocos.

I've not yet seen anything to make Chilli Source a bit easier to use. Even the basics such as making a sprite require about 6 different calls and the code is not simple.
This is the code I'm currently using to create my sprites (WIP Code, I know in_shareMaterial is never used):
` CS::SpriteComponentUPtr CreateSpriteFromSpriteSheet(const std::string& in_fileName, const std::string& in_spriteSheetName, const std::string& in_frameName, bool in_shareMaterial)
{
CS::IResourceOptionsCSPtrCS::Texture textureOptions = CS::IResourceOptionsCSPtrCS::Texture(new CS::TextureResourceOptions(false,
CS::TextureFilterMode::k_nearest,
CS::TextureWrapMode::k_repeat,
CS::TextureWrapMode::k_repeat));

	CS::TextureCSPtr texture = CS::Application::Get()->GetResourcePool()->LoadResource<CS::Texture>(CS::StorageLocation::k_package, in_fileName, textureOptions);

	CS::TextureAtlasCSPtr cardAtlas = CS::Application::Get()->GetResourcePool()->LoadResource<CS::TextureAtlas>(CS::StorageLocation::k_package, in_spriteSheetName);

	CS::MaterialCSPtr material = MaterialUtils::getMaterialWithName(in_fileName, texture);

	CS::TextureAtlas::Frame frame = cardAtlas->GetFrame(in_frameName);

	return CS::SpriteComponentUPtr(new CS::SpriteComponent(material, cardAtlas, in_frameName, frame.m_croppedSize, CS::SizePolicy::k_usePreferredSize));
}`

I've had quite a bit of experience with this engine, so I know how to build a sprite now but compared to other engines having to load a texture, an atlas, create a material (that must be unique no less, my material utils has a way around that) and get the texture atlas frame to get the sizing right, is just far too much work to do for a single sprite.
I would imagine that most people would write a utility similar to the one above to handle loading sprites, but I would request that Chilli Source provide some helper functions that make the most basic features easier to use.

I've just created a small menu system with a few buttons on it (labels with a function registered with the touch released event). Pressing on the buttons pushes a new state on top.

However, after I transition to the new states, whenever I tap where the menu buttons were the previous state's input events are still fired. Is this deliberate or is it a bug? My expected behaviour is that only the active UI canvas and widgets actually receive events.

A user friendly and extensible level/scene editor is crucial for a modern game engine.

I believe there's an assumption made when creating UI that the drawable object should be the original size of the image it came from. My assets are all from a 64x64 square and I'm using the packing process to trim the alpha to size. The reasoning for this is because I have all of my UI assets in one paintdotnet file and have a tool to export them as individual layers, which I then run through the sprite sheet tool.

What this means though is that all of my widgets need to be 64x64, despite the different sizes of the actual final image. This makes positioning difficult as everything has to take the sprite frame's offset into account and can't just be the size of the widget.
My expectation would be that the StandardUIDrawable would be the size of the parent widget. I understand this is not everyone's expectation as it's clearly implemented this way for a reason, so I would perhaps suggest a flag to turn on rendering with the alpha offset, or simply sizing the drawable to the widget size. For the moment I've replaced the render line in StandardUIDrawable::Draw with the following which gives me what I expect:
renderer->DrawBox(drawMode, transform, absSize, CS::Vector2::k_zero, m_texture, m_atlasFrame.m_uvs, absColour * m_colour, AlignmentAnchor::k_middleCentre);
changed from:
renderer->DrawBox(drawMode, transform, CalculateAlphaRestoreSize(m_atlasFrame, absSize), CalculateAlphaRestoreOffset(m_atlasFrame, absSize), m_texture, m_atlasFrame.m_uvs, absColour * m_colour, AlignmentAnchor::k_middleCentre);

I've had a couple of issues with the size of my UI images. The one I'm currently having is to do with the UI scale.

What I'm trying to do is have a 480x320 canvas and lay everything out according to that size. Then using the Widget's ScaleBy method to make it fit the screen. The reasoning for this is to simulate a much smaller resolution on a much bigger window.

However, after setting the scale on the parent widget, it appears that the size of everything increases but the absolute position does not. i.e. 10 pixels is still 10 pixels. If the scale were to be 3, I'd expect 10 pixels to be 30 on the child widgets's position.