Roland

Just a little note. if self.health >= self.maxHealth then self.health = self.maxHealth end if self.health <= 0 then self.health = 0 end could be replaced with self.health = Math:Clamp(self.health, 0, self.MaxHealth)

Updating to VS 2017 goes fine according to your instructions. Josh, now when you are at it, could you make the changes suggested below to get rid of warnings. A good project should compile without warning! Release cl : Command line warning D9030: '/Gm' is incompatible with multiprocessing; ignoring /MP switch Remove <MinimalRebuild>true</MinimalRebuild> from <CLCompile> section ------------------------------------- LINK : /LTCG specified but no code generation required; remove /LTCG from the link command line to improve linker performance Add <LinkTimeCodeGeneration>Default</LinkTimeCodeGeneration> to <LINK> section ------------------------------------- Debug Working Directory is wrong. Change $(SolutionDir)\..\..\.. to $(SolutionDir)..\.. ------------------------------------- Debug 1>libcryptoMT.lib(aes_cbc.obj) : warning LNK4099: PDB 'ossl_static.pdb' was not found with 'libcryptoMT.lib(aes_cbc.obj)' .... 1>libcryptoMT.lib(aes_core.obj) : warning LNK4099: PDB 'ossl_static.pdb' was not found with 'libcryptoMT.lib(aes_core.obj)'.... ... ... etc ... etc ... Add /ignore:4099 to <LINK> section, line <AdditionalOptions> ------------------------------------- Debug Working Directory is wrong. Change $(SolutionDir)\..\..\.. to $(SolutionDir)..\.. ------------------------------------- Thanks

Aha Great. My wallet became really scared and jumped under my table. Now I can tell it that everything is OK

No upgrade prices ?

Swedish is correct

Aaah. I see. Thank's (y)

Why not just use wstring, wchar_t, wfstream etc .. and that's it. A search and replace and maybe some modification here and there and its done

Cool.. didn't 'not' know that

while (not window->Closed() 'not'

I like what I see coming

Looks good to me

Yes that is even better. Will change my loops to that

Looks great This one could be even more simple for each( auto entity in list ) { entity->SetPosition(1,2,3); } instead of for (auto it = list.begin(); it!= list.end(); it++) { auto entity = *it; entity->SetPosition(1,2,3); }

Okay. Then I don't know. Haven't tested the new GUI my self yet.

Try with logTextArea->Release() instead

Great. All you who are interested just tell here

I'm going away for a roadtrip tomorrow and won't be back for three weeks. First thing when I'm back is to finish the LCS design editor and then start making some docs and tutorials. After that we will need some beta testers (you have already showed an interest in that). Anyone else is welcome. Will probably be in end of August if God and Thor is on our side. All this will be free when released.

So here is a small example of a game with a first person player with a camera. You can move the player forwards, backwards and turn him around. The camera will detect any items in front of the cursor within a limited range. If you left click on such an item when its detected it will go away, add health to the player and update a health meter showing current health. Here is a screenshot of the example (here with two different kinds of items to pick and two meters, but besides that its the same) Instead of diving into coding the player with all its operations to handle we won't in fact make any player coding. Instead we will divide things into components with their own responsibilities. The components is hold together by a runtime object created by LCS and is nothing you don't need to care about. So what is a component then. Its a LUA class that has Events and Actions and is completely isolated and independent of other components. This means it can easily be replaced with another component that behaves in another way. It can also without any changes be used in other projects. So how would we go about this then. First of all we have some entity's in our scene. Health items to pick up (the boxes) Player (a simple invisible cylinder) including a FPS camera HealthMeter ( GUI showing current health) Normally we the would have started making Scripts for those items above. But were not this time In fact none of the Entities in the scene will have a Script. Instead we are going to write Component scripts that can be used here or in some other game. So what components could our player need then? That's up you depending on how you want to design things. Here is a suggested approach by me. Input component that handles user input Controller component that handles movement of the player and camera Health component that keeps track of current health Cam component which is the FPS camera Further on the Health item needs a HealthItem component that reacts to a pickup and a HealtMeter component that serve as a GUI for current health. You don't need to write any Script code for the Entities in the Scene, only component needs some action by you. Each entity will be connected to a GameObject (which is generated in runtime and does not need any coding). This GameObject ties the components together and handles all things to get the communication going. The system is defined by supplying a setup written in JSON format. However you wont need to do that either as I'm currently working on a design application for setting things up and that will be available when we release the system. Anyway.. so now when we know what components we need, its time to think a bit on what they should to and how they will interact with the surroundings. So lets get started. I won't go through every component but I think you get the idea Input Should handle input from the user and generate events accordingly. An event can be subscribed to by any other component and sends some information about the event that happened. All events starts with 'on'. A subscriber of an event must have an action that will be triggered by the event. All actions starts with 'do'. Events onForward is sent when user presses 'W' onBackward is sent when user presses 'S' onClick is sent when user clicks left mouse button Controller The controller is responsible for moving the player Events onMove is sent when the player moves (contains information about current position) Actions doMoveForward moves the player forward doMoveBackward moves the player backward doTurn turns the player around its Y-axis (needs an angle) Cam Is simply the camera which is rotated by moving the mouse. Events onPick is sent if the doClick action is called when an pickable entity is in front of the camera. The entity is sent with the event. onTurn is sent when the user rotates the camera by moving the mouse Actions doMove moves the camera to a given position Here is a drawing showing our system now. The yellow parts are entities in the scene (map), the red ones are GameObjects created in runtime holding the components and finally the blue ones are the components which we have to write code for. L Lets have a look at the code for one of our components to see what it looks like The Controller class must have following functions to be treated as a controller by the LCS system init called by LCS to create the controller attach called by LCS when its attached to its entity and GameObject Besides those two, a component can (optionally) have following functions called in the same way as in normal Scripts. If one or more of those exist they are called automatically. update called on UpdateWorld updatePhysics called on UpdatePhysics draw called on Draw drawEach called on DrawEach postRender called on PostRender detach called on Detach In the init function you can see how an Event is created. That is all needed to create an Event. self.onMove = EventManager:create() If you then look in the update function you can see how the event is sent by calling 'raise' self.onMove:raise({Pos=newpos}) This event a contains a position. All event information are sent as tables. In this case a table member Pos set to the current position. Further there are some actions that can respond to events from outside world. Lets look at one of the actions function Controller:doMoveForward() self.move = self.moveSpeed end The action is just a normal function that may or may not have an argument. It does not need to return anything. One exiting thing is that all Actions are automatically executed as coroutines which has really cool advantages. I wont go into that here but I thought its worth mentioning. Here is a code snippet from the Cam component showing an action that can handle an onMove event that has an argument. function Cam:doMove(args) self.camera:SetPosition(args.Pos,true) end The args is the table sent with the event ( remember self.onMove:raise( {Pos=newpos} ) ). The args table will contain the member given when the event was raised. Okay. Lets see how all this works then In the diagram above you can see the components and the events in action. User presses W and Input:onForward event is sent to the Controller:doMoveForward action which make the player move forward The Controller raises the onMove event which is received by the Cam:DoMove action which moves the camera User presses S and Input:onBackward event is sent to the Controller:doMoveBackward action which make the player move forward The Controller raises the onMove event which is received by the Cam:DoMove action which moves the camera User moves mouse left and the Cam:onTurn event is raised giving the angle of rotation the movement caused. This event is caught by the Controller:doTurn action which rotates the player in the same angle User left clicks the mouse which raises the onClick event which is caught by the Cam:doClick action. If the camera now has an item directly in focus it raises an onPick event which then is caught by the entity's component HealtItem:doPicked. In doPicked the HealthItem will hide it self and send a message back to the player telling that it needs to 'add.health' among with the amount of health. The message will end up in the Health component (by magic ) and the health will be increased. As the health has changed the Health:onHealthChange event will be raised and is caught by the HealthMeter:doSetHealth action which will show the new health The communication between Events and Actions is set as hookups. A hookup means that a component subscribes to an Event. Take our onMove/doMove example above. Setting up a hookup for this is simple self.Controller.onMove:subscribe( self.Cam, self.Cam.doMove ) But that's done for you by the LCS system in the runtime GameComponent holding the Components for the player. How, you may wonder? This is done by creating a LCS project file (in JSON format) defining the GameObjects, Components and Hookups. Going into this in detail goes a bit out of scope for this 'short' description, but I can show a cut from that file { "source": "Controller", "source_event": "Move", "destination": "Cam", "destination_action": "Move", "arguments": "", "filter": "", "post": "" } This creates the hookup between the Controller and the Cam. This is only a simple example but you can add functions right here also for adding more arguments, making event filters and more. Code creation. One nice feature is when adding a new component by defining it in the LCS project file, LCS will create the LUA file for the component with everything added. The only thing you will need is to add some code inside the Action functions. As a last thing I will show how easy it is to take advantage of the actions which are coroutines (by magic). Here is how I raise the health level in the HealthMeter to be smooth function HealthMeter:doSetHealth(args) local value = 1 if args.Health < self.health then value = -1 end local goal = Math:Round(Math:Clamp(args.Health, 0, self.max) * self.valueSize) while self.pixelValue ~= goal do self.pixelValue = self.pixelValue + value coroutine.yield() -- give system some time end self.power = args.Health -- done! end Hope this have given you some more insight into the LCS system. PS: Some details has been left out here to increase readability

Really wonderful to see.

I can make one. Give me some hours An FPS player that can pick health items and have a health meter

Great improvement and finally fog. Thanks

+ it can't handle coroutines

In your Main.lua change context:Sync(true) to context:Sync(false)

Thanks for the update and I just say GO GO GO