Re: About Lua script

#2
Lua was the standard Cry Engine scripting language for a long time. It's very powerful and yet easy to use - it is compiled, but the game engine does this automatically.
Over the years I've created an advanced and unique simulator which includes aircraft, cars, trains, ships and spacecraft, and an autogen system which automatically generates scenery as you move along. You can fly thousands of miles and never reach the end of the scenery. I don't think anyone else has created anything remotely like this in Cry Engine.
The simulator is entirely programmed with Lua code.
I referred to it in this recent post:
viewtopic.php?f=40&t=11595&sid=b558e6d7 ... b2760a921e

It has been stated that Lua would be dropped in future versions. However, in the CE5 version I'm using (not the latest) Lua works fine, but you probably need to install GameSDK. Having said that, I'm not actively developing the simulator for CE5 as CE3 is far better for my purposes.
If you're interested I'd be delighted to discuss it more.
Chris

Re: About Lua script

#3
Lua was the standard Cry Engine scripting language for a long time. It's very powerful and yet easy to use - it is compiled, but the game engine does this automatically.
Over the years I've created an advanced and unique simulator which includes aircraft, cars, trains, ships and spacecraft, and an autogen system which automatically generates scenery as you move along. You can fly thousands of miles and never reach the end of the scenery. I don't think anyone else has created anything remotely like this in Cry Engine.
The simulator is entirely programmed with Lua code.
I referred to it in this recent post:
viewtopic.php?f=40&t=11595&sid=b558e6d7 ... b2760a921e

It has been stated that Lua would be dropped in future versions. However, in the CE5 version I'm using (not the latest) Lua works fine, but you probably need to install GameSDK. Having said that, I'm not actively developing the simulator for CE5 as CE3 is far better for my purposes.
If you're interested I'd be delighted to discuss it more.
Chris

Wow, this is awesome! I didn't know you are still working on it. I'm tracking your progress since the first "flyable aircraft / Spitfire" mod for Crysis. Free SDK is outdated, but the code can be easily ported to CryEngine EaaS 3.8.6, based on my experience. I'm not sure about CryEngine 5, which I don't like at all. You may want to try to use Lumberyard, they've got their engine almost the same as Eaas 3.8.6, Lua scripts should work.

I always wanted to ask, do you really like to use Lua everywhere, from the very basic concept up to the most complex systems? It seems like you are fine with it. It reminds me a Far Cry script system, where Lua was making all the hard job. It's just that the approach is different in the newer versions (CryEngine 2 and further), you make a base class/functionality in C++ code (a GameObjectExtension) and then add some functionality in Lua. This way it seems more integrated into the engine, plus you have an access to all advanced stuff that can't be just done purely by using Lua / Script callbacks. Like it would be nice to use Scaleform GFx interface for UI, make it look great (although it's possible to be done without C++ in CE3). And I guess the amount of script/code will be reduced this way. The Autogen application is probably also possible to be integrated into the code. So you can make it happen just inside the game.

Man, your project is A-W-E-S-O-M-E! This is one of those projects that never gets features on the main page, and this is what the whole place needs so much these days! I was always wondering if you will publish this project on Steam. Damn, that would just fantastic! You have this ability now, EaaS allowed hassle-free publishing on Steam. You can go and submit a project, make it free for everyone at the beta stage, and then evolve it into a fully featured set of simulators based on CryEngine. Indie gamers need you!

I wish you won't abandon this project. Please, make a MODDB or IndieDB page.

BTW, how happened that you lost your main account "cwright"? I know, they screwed up the whole website, and seems like they broke the account features like "remember password" and everything else. And they moved your main thread into "community archive", which is a dead pit. Should you just ask some moderators to move the thread into the world of life, I guess they will help you.

Re: About Lua script

#4
Hi silver008,
Great to hear from you!
Yes, I've been working on the simulator for quite a few years. It's come a long, long way since the days of the first Spitfire mod for CE2/Crysis.
CE3 is certainly long in the tooth, but I've found problems with CE5 and, like you I don't like it all that much. I think they've ruined the nice clean Sandbox interface and some aspects of the interface don't work properly, at least in the version I have.
CE3 is perfect for the simulator and I don't think any additional bells and whistles offered by CE5 are significant. The main drawback with CE3 is that it's obsolete and few people will be using it now.
Unfortunately I don't think EaaS is an option as, as far as I know, it's not open to new users.
I have used Lumberyard and it's still an option. Unfortunately any conversion to a new CE version will require a lot of work, one reason being that the current simulator uses a custom GameSdk dll made by another user (I/m not a C++ programmer).

Yes, I only use Lua ( and VB for the AircraftFactory program). It's surprisingly powerful and can access many game functions via the script bind libraries. I've played with C but I dislike it, I think it's ugly and unreadable. Also, with Lua I can edit the code, click Reload Script and instantly test the change in game mode, no need to reload Sandbox. This can make debugging much easier.

I've made a major addition to the simulator - I call it the world system. Now the Sandbox map is the size of the world - if you had the patience you could fly all the way from Heathrow to Australia. The code uses a world landclass database to construct terrain grids and to add autogen elements such as buildings, trees, roads, railtracks, AI trains and road traffic. When grids become too distant they are moved to a new location ahead and loaded with new terrain and objects, so you will never run out of scenery. Whenever the player moves more than 5 km from the Sandbox origin, the code moves *everything* back 5 km, so the player is never more than 5 km from the origin. These jumps are virtually invisible, which is amazing. By keeping the player close to the origin, the game engine vibration problems (due to low floating point precision) are virtually eliminated.

I've now integrated the world system with the spaceflight system. In principle you could make a journey by train and road to a spaceport, board your spacecraft and blast off into orbit, and then onwards to, say, Mars.

The simulator is completely free. If anyone would *seriously* like to try it then that would be possible. But, as a release would require a lot of work, I would need to be sure there was real interest. Sadly, it seems - in contrast to ten years ago - there's little interest. The forums today are a pale shadow of what they were ten years ago.

I've attached several screen shots of the (new) Spitfire and Harvard - the Harvard was the classic WW2 trainer used by the US and RAF.
In June I'll be going for a flight in a Spitfire and we will fly in formation with a Harvard. I've added this to tjhe simulator. It should be an amazing experience!

Once again, it's great to hear from someone who is actually interested!
Best regards,
Chris
Attachments
ScreenShot2739.jpg
ScreenShot2739.jpg (373.64 KiB) Viewed 2304 times
ScreenShot2734.jpg
ScreenShot2734.jpg (504.09 KiB) Viewed 2304 times
ScreenShot2727.jpg
ScreenShot2727.jpg (290.68 KiB) Viewed 2304 times

Re: About Lua script

#5
If you need a help with C++ porting for your GameDLL, I can try to convert the code for the newer version of CryEngine / Lumberyard. Honestly saying, I think the Amazon's version is quite experimental, although I didn't try the newer versions of the last couple of years. Yes, CryEngine 3 is outdated and CryEngine 5 is still in beta (in my opinion). But the newer the engine - the more reasons to actively develop your project. Anyway, if you still have this C++ source code, I think it's possible to convert it. I don't think there's really that much of a new code.

If you want to release with CryEngine 3 (Free SDK), I think it is possible to obtain a free license from Crytek to remove the CryDevLogin timeout banner on Launcher, or just release it "as is". If I remember it correct, a few projects managed to get the commercial license when there was only Free SDK available. I guess "Snow" was one of them. I think you can try to contact Crytek.

I also wanted to ask if it's possible to make a more arcade type of controls, like gamepad or KB/Mouse with more "gaming" controls than a simulator? I really liked the whole project, but I'm no really a fan of flying simulator control schemes, I find it quite difficult to control with keyboard/mouse without a special flight controller/stick system. I understand that such conversion will destroy some of the simulator's realism, but this can be optional (switch on/off in settings). I'm just thinking about those people who really want some arcade flying and enjoy the beauty of your game without professional knowledge of how to control a real life plane. Something like in Just Cause 2.

Lua is good, although its Basic-like syntax isn't so neat as a C-like syntax. However C++ can be frustrating for coders, I personally hate it. But when you work inside the project's environment, like a CryEngine, it becomes easier. You just follow the pattern and make your classes just like the other classes are made and using some premade functions/API. Much easier. And the new CryEngine 5 has a C# support, which has a hundred times better usability than C++. I've never used it with CryEngine 5, but C# can be reloaded on fly just like Lua. On the other hand there's a Live++ tool, which lets you hot-reload the C++ code if properly integrated into the project. Unreal Engine 4 uses Live++ in its latest version to let users make changes to the C++ code without reloading the whole project.

So, your world system takes a data from some kind of satellite/geo database, breaks it into parts, converts it to meshes, adds some buildings and then loads this stuff in real time into the map, completely avoiding the built-in terrain system, while constantly moving the reference point of coordinates, so you can do it forever. In other words, a perfect level streaming system with procedural generation from real-world database. Something that Crytek couldn't do for decades. Although I thought about something like that in general, it looks not so easy in practice as there's many difficulties, pitfalls and nuances to take into account to make this algorithm working properly. If someone told me to make it in CryEngine, I would say it's almost impossible. Hats off to you, sir! I can only imagine how cool it would be to use the full power of CryEngine, like the built in terrain system with voxels, better terrain textures and vegetation, and a world generator controls integrated into the Launcher's main menu.

And then a spaceflight system. Star Citizen took millions of dollars - everybody's pulling, but nothing is moving. The amount of hard work you've done in that project is enough for 2 doctoral dissertations. Your work is fascinating, it should not be left in oblivion. I honestly thought that the project was dead.

Yes, forums are pretty dead by now. I remember how glorious Crysis modding was 10 years ago. But we can't do anything about it. However today it's more feasible to gather your own community around your project rather than making some project for an existing community. We can do our projects ourselves today, no need for CryEngine's community approval. We've got much more sources for public attention than 10 tears ago when CryEngine was an almost unknown technology, with only Modding ability.

And I know how difficult it could be to finish some very personal work to the end and release it for the public. To get that attention, I'd recommend you to make a homepage or at least an IndieDB page, then a facebook group, connect them together and post some interesting stuff once in a while, along with writing some article about your progress. You will see in a couple of months that people are paying their interest to your game. Then you will see a Watchers/Followers numbers increase. You can make videos and upload them on YouTube. Find some community of air simulator fans, post there a video and a link to your game page. You can also have a Steam community group. Then find some popular YouTube channels and ask them to showcase a playthrough of your simulators. I'm 100% sure you will find your fanbase. And now that you can instantly upload any game on Steam with Steam Direct with just a $100 fee, you can publish your free game for millions of players without any need for Greenlight procedure anymore. Altogether will give it a proper attention and the desired interest.

So you will fly and control those planes for real? Wow!

Re: About Lua script

#6
Hi silver008,
At the moment I don't plan on moving to another version, but thank you very much for the offer. A user made the custom GameSDK dll quite a few years ago, but it made a huge difference for the simulator (e.g. it was no longer necessary to attach a flowgraph to every vehicle entity).
I believe he has the source code on Github, and I'm pretty sure I have a copy on an old computer. As I said, I don't have any plans at the moment, but maybe in the future....Many thanks!

For controlling / driving / flying vehicles the simulator has three options: mouse, keyboard and joystick. It uses a small utility to get joystick data directly from Windows. The code has full support for joysticks and you can assign commands to all the joystick buttons, sliders etc. I have used a Windows steering wheel to drive cars. Using game controllers should be possible, in fact I did exactly that for a group who were making a racing game. I think game controllers are basically the same as joysticks.
Mouse control works very well. Just push it forwards to make the nose go down (as the saying goes, push the stick forwards to make the houses get bigger). It's also perfect for driving cars.

Lumberyard is a possibility, particularly as it still uses Lua. I have several versions installed, and I may have a go at getting a simulator vehicle working in it. There's one promising thing. I tried a 14km * 7 km terrain grid in Lumberyard (essential for the world system). It was solid and the player can walk on it. A big problem with CE5 is that the terrain grids are not solid (you just fall through it). Unless Crytek will fix this then CE5 is a dead end as far as the simulator is concerned. Another essential requirement is that the game engine can support large numbers of brushes placed in entity slots (essential for the autogen system - it works well in CE3). When testing an early version of CE5 I noticed a serious problem that may indicate CE5 is inferior to CE3 in this respect. In extreme cases CE3 can handle around 20,000 brushes (they are loaded in large numbers of entities).

Your summary of the world system is pretty good! Here's a bit more info:
Just like FSX, it's driven by a landclass database that covers the world. It's actually an 8 bit colour .bmp, resolution 2784 * 2784. Each pixel sets the landclass value for one 14km * 7km terrain grid. This gives 256 possible landclass types, with zero = water. The bitmap is a map of the world and by editing pixels I can change the landclass for that area. The world is covered by 2784 * 2784 terrain grids, hence the resolution. It's quite low resolution but it works well (I think the equivalent resolution in FSX is 1 km).
The colour index for a pixel sets the landclass type e.g. 50 = green fields, 51 = green hills with hills, 80 = towns, 90 = cities. Values from zero to 99 are generic types. Values at 100 and above are reserved for detailed sceneries e.g. 100 = Heathrow Airport, 101 = Shoreham Airport - and 104 = Goodwood Airfield, from where I'll be flying in the Spitfire!
Terrain grids are 14km * 7 km grids modelled in Softimage. Some landclass types have several alternative versions, the code randomly chooses one to give more variety.
If one of the standard simulator asset files are placed in a landclass folder, then the code will automatically load the assets for the grid. They include:
1. A saved game file. This allows loaded terrain grids to spawn any number of vehicles e.g. Heathrow will spawn a set of aircraft that will taxi, take off, fly loops, land and taxi back to the takeoff runway. The saved game could even set up an aerial, naval or tank battle. One water landclass has several ships, a carrier and an F-14 that constantly lands on the carrier, taxis, waits and then takes off.
2. A Lights file. This will place lights on the terrain grid e.g. for towns or runway lights.
3. A standard Sandbox group file. The code will load the objects from the file onto the grid - this allows precise placement of objects e.g. of trees and buildings onto corresponding ground textures.
4. A layout bitmap and standard autogen data file. This will place autogen objects on the grid according to the layout set by the bitmap - the data file specifies the object types.
5. Road and railtrack data files. The code will create a network of roads and railtracks according to the data in the files. The roads will generate AI traffic and the railtracks will create AI trains.
6. Road/railtrack autogen file. This will add additional autogen objects along the roads and railtracks.
Once a landclass type is set up, I can splatter large numbers of instances of them all around the world just by painting pixels on the world bitmap.

As you fly or drive along, the code constantly checks your position in the world (latitude and longitude). Whenever you reach a point more than 5 km from the Sandbox origin, something amazing happens: *all* the map elements - the player, terrain, clouds, vehicles, roads and railtracks - are shifted back 5 km. Amazingly, these jumps are essentially invisible to the player. Many elements are children of a master entity, so for these only the master entity has to be moved.
Of course, as you fly along terrain grids will fall behind you. When they fall beyond a set distance, the code jumps into action. It deletes all the assets, moves the terrain grid to a vacant slot, and reloads everything - terrain grid and assets, according to the landclass value for the new position. It's set in Properties, but the default number of grids I normally use is 200, which gives a very good distant view distance.
The result is pretty amazing: you can fly the F-14 at supersonic speed over America and the scenery just keeps on rolling past - press CTRL-A to engage the autopilot. You could literally fly around the world.
It works very well (this is a tribute to Cry Engine).

The spaceflight system - developed some years ago - works in a similar way. The player spacecraft stays at the Sandbox origin - all the planets and other spacecraft are moved and scaled so that they appear in the correct positions etc. In the last few weeks I've updated it so that spacecraft use only solar system coordinates, even when on the surface of Earth. Each coordinate value uses four numbers, which massively increases the floating point resolution - even if a coordinate value is in millions or billions of kilometers it can maintain relative positions of adjacent spacecraft to a small fraction of a millimeter. This was particularly necessary as Cry Engine Lua uses reduced floating point precision. I've also now integrated the world and spaceflight systems and they work well together.

" I remember how glorious Crysis modding was 10 years ago."
Yes, me too. When I first discovered Far Cry and Cry Engine, it was a revelation. Almost every day there were new ideas, new applications, huge amounts of interesting discussion. Now it's all in the past.
Thanks for the suggestions. I certainly wouldn't use Facebook - you won't find me within a million miles of Facebook or Twitter!
But I definitely intend to make a youtube in the near future - the last one was a few years ago. I'll post it here and see how much interest there is - I suspect very little.

Best regards,
Chris
Attachments
ScreenShot2239.jpg
ScreenShot2239.jpg (312.18 KiB) Viewed 1957 times
ScreenShot2275.jpg
ScreenShot2275.jpg (319.14 KiB) Viewed 1957 times
ScreenShot2870.jpg
ScreenShot2870.jpg (530.97 KiB) Viewed 1957 times

Re: About Lua script

#7
It's really interesting, I would like to have some more technical information about the system, how the vehicles are done and etc. It would be great if you write some Lua / simulation articles, I bet a lot of people will find this really educating. Personally I've got lots of questions!

It seems like you use a local movement, is it correct? Can you explain how this is achieved?
Do vehicles use CryEngine physics system with collisions, acceleration/speed/gravity or it's also inside of the local movement system? Do these aircraft vehicles have a "real" CryEngine's physics, like propulsion, impulses, acceleration changing physical speed or it's like an object that's only changing vehicle's visible coordinates?
The same with the player: does it really move as a player class using the animation graph/articulated entity physics, or it's more like a moving camera, which is controlled entirely by your system? The player can walk inside of fast moving vehicles.
Can you make realistic cars and other ground vehicles with your system? How would the wheels be made then?

Even if you don't like Facebook / Twitter (I avoid using them too), you can rely on IndieDB - it's a great platform! Nice community, lots of players and thousands of modmakers/gamedevs. Your simulator project there will be just like the icing on the cake.

Re: About Lua script

#8
Hi silver008,
Some interesting questions!
I'm not sure exactly what you mean by "local", but the simulator can use local coordinates and this is one of its significant features. I'll cover this.
All vehicles (both player and AI) can switch to coordinates local to another vehicle. In other words, one vehicle can be a child of another parent vehicle.
Suppose you fly an aircraft onto the deck of an aircraft carrier (see screen shots). If the carrier is set up to be a parent, when the aircraft touches the deck it automatically switches to local coordinates (local to the carrier). This means that now the aircraft will be "carried" by the carrier, just as in the real world. You can then taxi on the carrier, although the carrier may be going at full speed. Other simulators may have been able to do this, but I don't know of any: in commercial simulators I've used the carriers were simply static objects.

If you make a takeoff run, when the aircraft lifts up the attachment is automatically disabled, and the aircraft flies normally. However, AI aircraft can be set to permanently run in local mode (a child of the carrier). It can then follow waypoints which are local to the carrier. This makes it possible for an AI aircraft to continuously fly around the moving carrier and to land on it etc. Other examples of vehicle attachment: AI cars driving onto train wagons (they will then be carried by the train); a car or tank driving into the hold of the Hercules - when the Hercules takes off the vehicle will be carried as cargo. After landing the player can drive the vehicle off the Hercules. In theory it should be possible for an aircraft or helicopter to land on a moving AI truck - I must try it some time!

I don't use the game engine vehicle system in any shape or form. Instead all the necessary physics is handled by the Lua code. For example, all the forces acting on an aircraft - wing lift, aileron and elevator forces, friction and undercarriage forces - are included in the code. This gives me full flexibility. Once the forces are calculated it's easy to calculate the acceleration, velocity and positions in each frame - it's basically Newton's laws of motion.

Normally I don't use the game player. Instead I use an entity named "Walker". It's actually a vehicle, the main difference being that it runs on legs instead of wheels. By the way, all vehicle Lua code is generated by my Aircraft Factory utility. If you create a new vehicle type, you would create it in AF, set all the settings as required (e.g. the model path). When that's done just press the Build Vehicle button and it will create around 6000 lines of Lua code in a couple of seconds. The code is stored in a set of code library files. If I change the code, after testing I update the necessary library files. I can then update all the vehicle codes by running AF in batch mode - all the vehicles will then have the new code in a few seconds. Without Aircraft Factory it would be a nightmare updating all the different vehicle codes whenever I make a code change, such as adding a new feature.

For a map with Walker enebled (by Properties), when you start game mode you are placed in Walker. You can look around by moving the mouse. You can use WASD to walk, but you can also use the mouse buttons which is far more convenient (I never use WASD). In game you can also change walk speed and height with the mouse. You enter any vehicle with the F command - but the Walker code can make intelligent decisions as to which vehicle to enter e.g. if you're next to a truck parked on a carrier it will choose the truck, although you're in range of the carrier as well.

In the vehicle, you can still use walk mode with commands identical to Walker. In walk mode you can naturally walk around the interior of the vehicle even if it's driving or flying at speed e.g. the Constellation cabin.

Yes, the simulatir has full support for ground vehicles, the screen shot shows the Cobra and also some AI traffic. The suspension physics is in the Lua code and it works very well. Driving the Cobra or Aston Martin is pretty amazing - not quite Need for Speed but close! The code senses the terrain height at each wheel position and calculates the forces accordingly. You will crash if you hit another vehicle but currently it doesn't crash when it hits static objects. There is a Lua collision scripbind call, but I could never get it to work. At some stage I'll probably write some custom code to implement collisions with static objects. Possibly driving fast cars is the most fun part of the simulator. You can use a Windows steering wheel as well as joysticks to drive. For a long time I've been thinking of using this as a basis for a racing game.

"How would the wheels be made then?"
Each wheel is an object placed in the vehicle entity slot. The angles of a slot object are set by self:SetSlotAngles(angles), so the wheels are rotated at a rate proportional to the forward speed. The position is set by self:SetSlotPos(pos), so the wheel is moved vertically according to the suspension force. Similar code is used for aircraft undercarriage wheels. Here the wheel slot objects are set as children of the undercarriage itself, so as the U/C rotates the wheels stay attached to it.

I took a look at IndieDB, it looks pretty good. However, I possibly can't claim to be an indie developer as the simulator is completely free!
As I mentioned, I definitely will try to make a youtube in the near future.

If you would like to read the HTML manual, let me know. It contains a lot of information on the simulator. However, in the good old days I could simply upload the html and image files to Dropbox and it would display it correctly. Sadly they dropped that, so it would have to be in the form of a zip file that would be unzipped to any location.

All the best and keep the questions coming!
Chris
Attachments
ScreenShot2899.jpg
ScreenShot2899.jpg (261.15 KiB) Viewed 951 times
ScreenShot2884.jpg
ScreenShot2884.jpg (557.35 KiB) Viewed 951 times
ScreenShot2911.jpg
ScreenShot2911.jpg (335.51 KiB) Viewed 951 times

Who is online

Users browsing this forum: No registered users and 3 guests

cron