twistking

Do you have any info on the relative size of the assets packs? I'd assume that M3's asset pack will be rather limited in size but free (to be shipped along their corsair), while ED's effort seems to be bigger with the heavy cruisers, enterprise and zeros already shown... With the marianas map being free, it would only make sense for ED to also bring their assets for free... Maybe we'll also see a shift in asset pack policy - as was rumored with the recent AI aircraft "controversy"...

Of course this would also apply to modern DCS, but especially the PTO will rise or fall with ship damage modelling. I think we can all agree, that a purely hitpoint based system simply won't cut it. I think ship modelling should at least have the following features: - Damage must be seperated from flooding (buoyancy), meaning a "destroyed" ship can still float and a "not destroyed" ship can still flood and sink - Flooding must take compartments into account - at least in a simplyfied manner - Different parts of the ships take damage and fail individually - Ideally there was also some limited (!) self-repair (stop flooding, stop fires) tied to a "crew status" value. "Crew status" would decrease through hits, with lower values limiting and finally stopping self-repair capability of the ship. If "crew status" is completely depleted, the ship is abandoned. - With this there would be three basic kill types: 1. Sinking, because of flooding a set amount of compartments. 2. Ship fuctionally destroyed (superstructure, weapons etc) but still floating without power. 3. Ship abandoned because of depleted "crew status". Similar to previous point, but visibly different (less destruction) and maybe a more realistic result for a bigger, heavily armored ship (in reality high casulties and spreading fire could trigger an evacuation without the ship being completely destroyed or sunk).

this

I've witnessed the same. Breaks all my missions actually.

Are we sure that this is not just an A-8 Anton pretending to be a zero?

Without adequate search radars (and without the possibility to connect to an IADS) the S-200 system is really pointless currently.

i just noticed that on marianas map there are no contour lines at all. wasn't sure if that qualifies as a bug, so decided to bump this thread instead.

It's terrible design to have to adjust every waypoint's values, if you want to tune a flightpath for ToT or just change altitude for a complex flightplan. I propose that instead of needing a number input on those fields, the editor would accept variables and basic operation. For example you could put "blu_cap_1_alt" in every altitude field of the flightpath. For certain waypoints you could put f.e. "blu_cap_1_alt + 1000" to modify the altitude per waypoint relative to the base value. The variable would need to be set at mission start. This way you could easily change while complex flightpath with only a single edit. You could maybe also change the variable during mission for the change to take effect once the flight passes the next waypoint and the fields get read again with updated variable. With this you could also do some quick randomization by having the variable value be selected from different possible values at mission start.

*bumb* I think that besides the missing undo function, the lack of quick and easy randomization is what makes the editor feel so archaic.

i think the DCS editor is already setup quite well for this actually, as it somehow already renders the original terrain textures. Also since SAM sites are - more often than not - set up on relative flat terrain, just projecting the texture flat from above should be good enough. Remember that those dirt roads and tire marks don't have to be super defined and crisp, you could never tell if they were warped a little bit, because of skewed projection. The most splendig solution would be of course to have the engine generate those marks from vector data, so mission builder could just paint in their patterns, but that seems to be overkill. I think it would be good enough to have a selection of patterns (a few complete sam layouts and some smaller building block textures consisting of various patches and paths) with variants to fit different bases (grass, sand/dirt, snow...)

Make doodles on the map, that are optionally MP-synced and will show up on the kneeboard map Have the planner automatically scrape the mission file for all relevant radio frequencies and be able to select which of those frequencies will automatically populate a generated kneeboard page Be able to select airports and nav beacons which will automatically populate a generated kneeboard page with frequencies (nav, atc, ils etc.) Have the planner scrape your user folder for custom kneepage pages and be able to select which of those to include

Hello, i've created a MP mission on current stable branch that seems to run fine in SP (not tested enough to be sure), but has a very high change of crashing the host when running in MP. Tested both on dedicated server and client-hosted. In both cases the mission crashed the host at some point. In all crashes clients would not time out immediately, but client simulation would keep running with working VoIP with all AI units being frozen in place. Only when host accepted the crash message, the session would completely terminate and clients would time out. No mods, stable branch, no custom lua scripts, only vanilla editor logic. There is nothing special about this mission. I've included logs from 3 sessions. One was hosted on dedicated server, the others were hosted from client. I've also included the mission file, however it should be noted, that there were some very minor (!) changes to the mission file between the sessions/crashes. dcs.log-20231226-212215-clienthost.zip dcs.log-20231226-232357-clienthost.zip dcs.log-20231230-215353-dedi.zip F16C_Show_Of_Force_01.miz

wold probably be way easier (and maybe even more flexible) to have civilian traffic excluded from editor placed trigger zones. either way it would be a good feature and it has been requested a few times already!

I would guess that the AI calculations and network parts are also on one thread when self-hosting from regular client. Or in other words: The actual hosting part is equally singlethreaded on both self hosted clients and dedicated servers. That's just an educated guess though. I simply suspect that both client and dedi share parts of the same codebase and that both will benefit when ED eventually further improves multithreading for AI and networking...

I see! Thx!

in this case client aircraft would still spawn at their initial position though, correct? so if you pause server mid-mission and exit client, on reconnect client would be back at initial spawnpoint, or could client reconnect on last position mid-air?

To be fair, in the DCS scrennshot posted by the OP, the weapon does indeed look more glossy. Lighting might be different, but if i would have to judge only from the images provided here, i'd be inclined to agree witht he OP...

No Problem. Thanks a lot!!! Another reason less for me to use dedicated then, but i guess it's still nice to have the options and it's indeed nice to have a (dedicated) host not being affected by clientside crashes.

thanks for the reply. much appreciated! so there is no way to restart missions when self-hosting, correct? i think the option to restart mission without restarting the whole session is very important, so it seems weird that you need the dedicated server to be able to do this.

We recently tested the dedicated server tool for hosting MP and while setup was easy, we did not see any differences in performance (my missions are very light to not overburden weak clients, so the server overhead from AI and networking seems to be minimal). I did hoewever get a game crash on my client (doesn't have to be related to hosting from dedi of course). I also missed the option to pause and resume mission by keyboard that you have when self hosting. The only notable advantage of using dedi was the option to quickly restart a mission without restarting the server. Some questions: - Is hosting with dedicated considered as stable as self hosting (bugs, crashes, glitches), or is dedicated still somewhat WIP? - I remember bug reports of AI behaving differently on dedi vs self hosted. Are these issues and inconsistencies fixed? - If performance isn't a big concern, because of lightweight missions, what are advantages of using dedi for private CoOp? - Is there a command to restart a mission when self hosting without terminating the game session and creating a new game (this was the only obvious advantage we found with dedi)? Thanks.

Hello, when self-hosting MP a mission or playing/testing a MP-compatible mission in SP, the initial world position after loading the mission (background of lobby screen) is centred on the redfor aircraft with the lowest id and if no redfor aircraft is found, it is centered on the blufor ac of lowest id. Knowing this was useful, because with using "late activation" of certain assets, you could force the initial camera position at a certain point. This way you could minimize loading times and data shuffling when loading into the cockpit for the first time, because ideally the initial camera position was close to the aircraft spawn position (this is only viable for CoOp obviously - where all player share the same starting airport). We recently tested hosting with the dedicated server tool and while all worked well, i noticed that my camera "hack" did not work anymore. The initial camera was centered on a random airfield (if i remember correctly: abu musa island in PG map). My question would be, if there is a way to change the initial camera position of a mission when hosting it with dedicated server and how the initial position is decided. If possible i would like the initial camera position (the view of the world in the background when lobby screen is shown after loading) to match the location of the airport the players will spawn on. Any ideas why this behaviour might be different between self hosted games and hosted from dedi?

i'm quite happy to hear that. I think the current system is not an optimal solution and that there's potential to make it better for all. Even though i don't play public MP, i still very much understand @Dangerzone's arguments and my frustration (as a stable-enjoyer) is rooted in - at least- similar issues. I want to add a completely different and unrelated point of critique though: I have only anecdotical evidence unfortunately but i suspect that having the open beta the "standard" for the (public) MP community significantly reduces the quality of technical feedback (bug reports) from what is supposed to be a testing branch. I chose stable branch, because i don't like to deal with bugs and issues and very often i still encounter a new bug in a stable release, that is not yet reported on the forums, despite the open beta being available for month at that point. And i'm talkin "proper" bugs: Little things that broke with an update as compared to "complaining" about long standing issues (which i also endulge in a lot). On other games that have an explicit "testing branch" version before complex updates, i feel that both quantity and quality of user feedback is way better, because users make a conscious decision to download said branch to help with testing and don't just download to get the new shiny stuff. I bring this up, because i think that there can be a lot of value in having a seperate testing branch, because there are a lot of users who actually want to help with testing. It's just that i'm not one of them... and i think that letting the test branch become the standard for many (most?), will muddy down the feedback quality eventually.

it would be great, if we could get procedural snow-coverage, where snow would show on the ground and objects depending on meteorological conditions. if the promised weather simulation has high enough resolution, that could actually be feasible.

isn't "direct storage" what you are asking for really? in the end it doesn't matter really matter how exactly the "direct storage" data-streaming is archieved, but it will matter, if it is vendor agnostic or not. that said, this is surely a technology that would make sense with DCS, however i'm also sure that ED could alleviate all IO/texture bottlenecks, if they would finally start to properly master/optimize their assets/textures instead of just continueing to push 4k auxiliary maps for even the tiniest of objects. it's a waste of rescources and while retooling the whole spaghetticode renderpipeline probably is a daunting and very difficult task, simply optimizing assets and establishing optimization workflows for future assets is just plain old busywork and nothing more!