Bluestream

I've been trying this out in coop with a friend for a bit. We can't talk to AWACS or other flights in the same package, despite being on the correct frequency. They also seems to be missing a callsign whenever they say things. Any way we can fix that?

Wow, thanks again for all the feedback. I realise that some of the things I blurt out may be hard to follow since this is kind of a brain dump at the moment, I apologise for that. Anyway, I'm going to try to quickly respond to the points you've all given since I really appreciate it. It's cool, I like it! I also feel the pathfinding will be a problem and I'm having trouble seeing any easy solutions at the moment. I believe I may need to use exported map data (like [FSF]Ian's idea above) if I want to get it working perfectly. Persistence on the other hand is already pretty much a solved problem in the campaign, it's actually not dependent on mission files at all. I can just kill the DCS process at any time and start it back up and it'll load up as it was (perhaps with a small rollback of a few seconds or so). I'm not currently saving everything either, actually it's just living unit groups for now, but I believe that the concept is working well and adding to it will hopefully not cause too much headache. Oh, and for now the player group is not saved by the campaign either, so player state will not save. If anyone wants more details on this I'd be happy to explain it in more depth. I'm really happy to see more people working on campaigns, I also feel this is something DCS really needs! I'm currently avoiding in-sim calculations as much as I can but throttling any calculations that I need to do sounds like a good idea - that may be relevant for exporting group data to the .NET app in the long run. Also thanks for the offer, I'll keep it in mind. The same goes the other way around for anyone, if you believe you could use the source for any particular part of my mission before I'm releasing it, just ask and I'll see if I can give you something (if it's working well enough). Yes, this is a really good idea, expecially about using units that doesn't spawn to get routes, that's something I'll really look into for the simulation side of it as well. I guess just placing units with waypoints that cover all the roads would be a nice and quick way of exporting the road data! I could then have a few set entry/exit points (on roads) to strategic locations and as long as the units do not get stuck while moving to/from the 'entry points'/'exit points' to the locations it should be fine, it wouldn't be perfect and I believe it would still fail sometimes, but it would be good enough for now. It's actually not limited to airports/airfields, but it currently is limited to capturable zones, that is no buildings to bomb or anything like that. The reason I mention airfields is that the AI usually behaves reasonably well there. The objectives can currently be any zone marked in the default DCS mission editor. When starting the campaign for the first time, this information will be fetched from DCS once and used by the .NET application. I agree I think it will override a few limitations, but it also creates a few problems, I have to develop the API between Lua and .NET for example. The overall greatest positive about it for me is that I can use an environment I'm comfortable with that comes with a good debugger. I have no doubt that someone who knows Lua well would not be hindered by working only with Lua, in-sim.

Thanks to everyone for the encouragement. That map looks really interesting. Just out of interest, how did you get the data for it? If you've explored the possibility of an A2G campaign a bit before, maybe you're aware of some of the pitfalls along the way. I'll make sure to send you a PM. On another note, I've been reading up on (the basics of) AI and common design patterns around that, and I'm implementing a variant of Goal Oriented Action Planning. It seems easy enough to understand and so far isn't too hard to implement. I found a pretty good explanation of it here if anyone's interested: http://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai--cms-20793. The exact implementation I believe has a few problems, but it explains the method very well. Currently I have a red and a blue side spawning units and fighting over a few objectives, marked as zones in the mission editor. The zones are captured when only one team is present within and ownership is tracked by the external application. Zone ownership is not visible in game yet, but they AI do respond to it, they won't send units to a zone they already control. I'm struggling a lot with the pathfinding of the AI right now, they seem to get stuck all the time due to buildings and bridges etc. For example, I cannot get a group of 4 vehicles to move from Kobuleti to Batumi off road without getting stuck. Anyone else seen similar things? I'm not sure if going on road will solve anything since units will probably be spawned in pretty random locations if they have been simulated, so they have to be able to go off road without getting stuck sometimes. Going to have to think about this for a while. Next up after that is simulating the same thing when units are not spawned in (if the player is too far away). Doesn't sound too hard but there are a few things I need to account for, like making sure they do not attempt to cross the ocean to get where they're going. I'll try to keep it as simple as possible though.

I'm not sure yet. I'm also thinking that maybe it doesn't need to be a bubble exactly. Spawning the 'x' closest units to the player could also work and may be better, if it doesn't cause too much trouble with the simulation. Ultimately it'll (size or spawn range) depend on number of AI. Lots of AI = needs shorter range, small amount of AI = range can increase.

Hi everyone! I want to share a little project I'm working on - a sort of dynamic campaign, at least it's a start I guess. I'm creating this thread to share some of my ideas and explain what I'm currently doing. I think it will help keep myself motivated and hopefully I'll get some ideas from all of you as well. Plans for the first release My plan with this is to try and keep things simple to start with to have something release-ready as soon as possible, and then to keep improving it from there. That means that this will not even be close to as in-depth as the F4 campaign, or any other dynamic campaign that we imagine, anytime soon, if ever. These are some things that I'm hoping will be in the first version: All living units are persistent between missions. (Does not yet include damage, loadout, ammo, wrecks, static objects) The campaign is run by an external application that will be running alongside DCS throughout the mission. I'm going for "bubble" around players approach, I believe this is the only way currently. What I mean by this is that enemies close to you will be spawned within the DCS world and the rest will be simulated by the external application. I'm focusing on A2G first, since I like to fly the A-10C. Capturing airfields will be the objective and is probably done by destroying most enemy forces in the area. Each coalition will have a set maximum amount of units the can be on the battlefield at once. Units spawn at a set position and will have to move from there, so no instant reinforcements. Each coalition has an AI that makes large-scale decisions. For now it will be able to send AI units to capture or defend airfields. Some kind of basic task/mission generation. This may seem a bit lacking, but I think it's important to limit the scope to avoid ending up bored with slow progress. I would prefer being able to release something playable (even if it won't be fun at all) that can be improved, rather than trying to do too much at once and giving up. Current status Right now what I've got working is an external application that is able to communicate with DCS over TCP (during the mission) to track units, spawn/despawn units in the DCS world depending on player position and set basic tasks for units. I have also started developing a pretty simple AI that can make decisions on where to send units based on a few input parameters. For the technically inclined, here's a short description of the three major parts in this project. An external application The external application is written in C# using .NET (because I know it well and therefor it allows faster development by far compared to Lua for me). When started it sets up a TCP socket that waits for DCS to connect to it. When a DCS client has connected it will request some static data from DCS. This includes airbase locations and trigger zone locations. It will also receive messages containing group data (positions, unit types, current tasks etc for all unit groups that are spawned in DCS). The applciation also tells DCS to spawn or despawn units depending on player position. All communication is done using JSON messages since there are good parsers available in both .NET and Lua. In theory this could be running on the same computer as DCS or another computer, it wouldn't matter, but for now I see no real reason to run it on another computer. Lua script The Lua script is run by the DCS mission and will handle all requests sent from the .NET application. It can currently, spawn/despawn groups, get group data, forward some events, get airbase/trigger zone data and send/receive messages to the external application over TCP using LuaSocket. An HTML5 interface and REST API This is basically just a WebGL application that currently draws a map with markers for airbases and markers for units. It can do this by using the REST API that is exposed by the .NET application. It currently does nothing that the built-in DCS map doesn't do better (except it shows units that aren't spawned in DCS, which may become handy for debugging in the future I guess). If I decide to continue down this road in the future this will be the campaign UI. Since it's web-based, this UI can be accessed from anywhere you wish. This may seem like a weird thing to do, but I'm also using this project as a way to learn a couple of new things, web development is one of them. Thanks for reading! When I feel ready to, I'll put it up on github. I appreciate any thoughts you may have on this, hopefully it seems interesting, and if not at least I think I got some clarity of my own thoughts by writing this.

Alright, then I understand. Thanks for the clarification.

Hello! So I'm considering buying the F-15C, I already own the A-10C and I'm having a lot of fun with it. My question is though, there are two versions of the A-10 currently, there's the A-10A that you get with FC3 and the standalone C version aswell. I'm under the impression that ED will make a more advanced version of the F-15C aswell in the future (like they did with the A-10). So what I'm wondering is if I buy the F-15C (the standalone one that is also included in FC3) does that mean I will also get the more advanced version of it in the future when that is released or would that be another purchase whenever that's out (of course, I realise this may be a while)? The reason I'm asking is because they call the current standalone F-15C an open beta. An open beta of what? FC3 has been out for a long time now and there's no beta of that. Would be nice if someone could clarify this for me or point me in the right direction. Thanks.