******Official Star Citizen / Squadron 42 Thread******

@ttaskmaster That physical switches etc on the throttle was the one thing I really loved about my Warthog hotas I had a few years back. Problem is, now I'm on Virpils and I like things to match. I've asked Virpil if they've got plans for control boxes that match the constellation asthetic and got a standard none answer.
 
Last edited:

I wonder how advanced a physicalized damage system will be for ships, to the extend where you could practically cut a ship in two (going layer by layer) still on the table?

And in other news, since the ships were made based on current "planet ships", with glass cockpits instead of an actual starship design would be... a rocket or heavy damage to a smaller or larger ship that has a (basically) cockpit glass / window is game over for that one? Or you just aim a repair took thingy at the place where the glass should be an magically appears back? Same applys to other material walls between two rooms (or between the inside and outside of a ship).

PS: So they show a fire on the cargo bay, he opens the door to kill said fire by starving it of oxygen, but no rapid decompression happens and the fire doesn't respond by being "pulled" towards the place where the air would go... Fingers crossed details like these get fixed as otherwise it does look very good! :)
 
I wonder how advanced a physicalized damage system will be for ships, to the extend where you could practically cut a ship in two (going layer by layer) still on the table?

And in other news, since the ships were made based on current "planet ships", with glass cockpits instead of an actual starship design would be... a rocket or heavy damage to a smaller or larger ship that has a (basically) cockpit glass / window is game over for that one? Or you just aim a repair took thingy at the place where the glass should be an magically appears back? Same applys to other material walls between two rooms (or between the inside and outside of a ship).

PS: So they show a fire on the cargo bay, he opens the door to kill said fire by starving it of oxygen, but no rapid decompression happens and the fire doesn't respond by being "pulled" towards the place where the air would go... Fingers crossed details like these get fixed as otherwise it does look very good! :)
So physical damage will never be at that level. But stress/strain will mean where they desig joints that is where parts will break away from like the wing from the hull. Doors will likely get marked up for cutting ability.

In terms of the glass in lore it basically stronger than the metal hull just to stop pilots being shot up and allow wi down to be modelled on ships.

No idea how far they will model fire. They also need to think about what happens with fire in zero g at some point
 
So physical damage will never be at that level. But stress/strain will mean where they desig joints that is where parts will break away from like the wing from the hull. Doors will likely get marked up for cutting ability.

In terms of the glass in lore it basically stronger than the metal hull just to stop pilots being shot up and allow wi down to be modelled on ships.

No idea how far they will model fire. They also need to think about what happens with fire in zero g at some point
HAAHAHAHAH! Then make the ship entirely from glass! :D How about the visor from the spacesuits, same thing?

As for the damage model, I'll wait and see. But definitely will be interesting to see how they resolve some issue(s) with significant damaged vehicles and how they'll behave in space and on planets (including disintegration in the atmosphere, for instance, if you decide to "land" with severely beaten ship). And some advanced destruction should be required for the salvage gameplay loop.

Frankly I'm supper excited to see this being pushed as much as possible. The gameplay diversity and implications would be huge!

 
Last edited:
HAAHAHAHAH! Then make the ship entirely from glass! :D How about the visor from the spacesuits, same thing?

As for the damage model, I'll wait and see. But definitely will be interesting to see how they resolve some issue(s) with significant damaged vehicles and how they'll behave in space and on planets (including disintegration in the atmosphere, for instance, if you decide to "land" with severely beaten ship). And some advanced destruction should be required for the salvage gameplay loop.

Frankly I'm supper excited to see this being pushed as much as possible. The gameplay diversity and implications would be huge!

Haha I know right. Non idea on visor.

For the physics and damage model we really don't have a way in game to make elements truly act like a real element. They have explained how it will still be chunks of ships similar to that shown in the engine demo. It will need manually marking up where joints are of a structure so those will be the breakable pieces.

Maelstrom will then calculate stress and fatigue based on damage being sustained by the structure and when a joint is overwhelmed then it will fail and thar structure fails.

If you are missing structure/elements that would have thrusters etc don't expect it to fly as they are missing etc.

Salvage gameplay is gone of dodo to what wanted/expected honestly. The claw goes, cutting elements up at the joints to then get munched. Just all gone with currently devs unsure how to make it work if at all will now. At least that was discussion had when at the party after citcon last year. The only really physicalised gameplay loop they still looking at is cargo side.
 

Yeah, those.
In the case of the VKB owners, most of their modules can be integrated directly to the base HOTAS kit.
Virpil stuff is really nicely made and uses a lot of metal construction to give the impression of solid build, although beneath that they really use the same components as all the others. Virpil are mostly generic flight-sim style, whereas VKB have more of a spaceshippy aesthetic to them.
 

I get the sense reading this we are in for the long haul on it, there is no 4.0 this year, it is not in Q1 25, maybe Q2 25, might not even be ready Q3 25.

Everything with CIG is multiple years.
 
Last edited:
I actually didn't read it at all like that if they moving with weekly updates and seems like they pushing to get it cleaned up for a 4.0 into evo testing probs after the next big ship sale.

Nothing have they ever done has been weekly solid patches pushing to get things tested and with proper feedback. I'm sure you've seen the chat about there being another test end of week with updates based on the last test with further optimisations and such.
 
I actually didn't read it at all like that if they moving with weekly updates and seems like they pushing to get it cleaned up for a 4.0 into evo testing probs after the next big ship sale.

Nothing have they ever done has been weekly solid patches pushing to get things tested and with proper feedback. I'm sure you've seen the chat about there being another test end of week with updates based on the last test with further optimisations and such.

I think it will take them months to get it working without any of the missions running, outside of 4.0.... then they will port it in to 4.0 and most of it will break wasting months of work they will have to do all over again.

Things that look like they should take weeks or months have taken years so for me that is what i have come to expect, there is always something that needs doing or fixing first and its a multiyear project.
 
Last edited:
I think it will take them months to get it working without any of the missions running, outside of 4.0.... then they will port it in to 4.0 and most of it will break wasting months of work they will have to do all over again.

Things that look like they should take weeks or months have taken years so for me that is what i have come to expect, there is always something that needs doing or fixing first and its a multiyear project.
I don't think that's the case. Mission refactor will yes break a few things here and there but that is ab overlay of software built on the mesh, not the other way around. If the mission system was the foundation then that would be different and indeed correct.

Look at it as SM is the foundation. That needs the weeks and months put into it (October and November in this case) and then you overlay the 4.0 stuff in the merge branch that are the structural walls like the transit system and mission system refactors. Those should be layers on top and planned for thus not requiring the foundations to be fully reworked.

There will be bugs and issues course because edge cases and 30k issues and that. Plus we know it's a multi year project. They been on this road for this since at least 3.18 with this tech build.

This is the most positive I've actually been that SM and that is even the right direction and going to be viable in any way since seeing the CitCon demo principles
 
Last edited:
I can't get my head around why they are building a 4.0 with a lot of its own modifications and updates while the bit that's critical to 4.0 is being R&D and bug chased on an obsolete build.
Server meshing on a known build with known bugs is much easier to build and develop on. They can also compare direct data of existing build and format. They aren't bug chasing fixes for 3.23 build, purely on the critical path for SM which is very different.

The other build of 4.0 in terms of merging across relies on SM rather than other way. So they are aiming to get SM stable and the build 4.0 onto that.

If you try and develop 4.0 on SM as it stands you will be chasing tails for months or years without the data to know where bugs are coming from.

Plus what does 4.0 bring that will significantly affect server meshing where SM needs major overhauls? We already have a star system, so be it stanton or pyro is irrelevant. Engineering gameplay has been on a 3.2X patch for a while though AC. The room system to an extent has been in partially for a long time. There isn't huge chunks of further back end at all with new requirements on the 4.0 branch.

The stuff built in 4.0 at min can mostly work on a 3.23 branch anyways, there a reason they are bringing for instance the MFD updates sooner.

Note a lot of what will come in 4.0 is also initially being developed on a version of the 3.23 branch. You need to test those elements just the same as SM. It's just that they are not doing that via the tech preview. Not a need. 4.0 first push will be internally to then shift SM to a 4.0 branch and then push a chunk of updates critical so most likely transit and mission side. The other updates for gameplay, locations are all secondary updates. You don't need them for 4.0 in terms of code.

8 to 10 weeks worth of iteration on the systems they have got and then it being pushed to what will make the 4.0 wouldn't be unsurprising considering where tests are at now.
 
I can't get my head around why they are building a 4.0 with a lot of its own modifications and updates while the bit that's critical to 4.0 is being R&D and bug chased on an obsolete build.
To offer players the opportunity to look for the same bugs they's reported a thousand times before. They know we love it.
 
Server meshing on a known build with known bugs is much easier to build and develop on. They can also compare direct data of existing build and format. They aren't bug chasing fixes for 3.23 build, purely on the critical path for SM which is very different.

The other build of 4.0 in terms of merging across relies on SM rather than other way. So they are aiming to get SM stable and the build 4.0 onto that.

If you try and develop 4.0 on SM as it stands you will be chasing tails for months or years without the data to know where bugs are coming from.

Plus what does 4.0 bring that will significantly affect server meshing where SM needs major overhauls? We already have a star system, so be it stanton or pyro is irrelevant. Engineering gameplay has been on a 3.2X patch for a while though AC. The room system to an extent has been in partially for a long time. There isn't huge chunks of further back end at all with new requirements on the 4.0 branch.

The stuff built in 4.0 at min can mostly work on a 3.23 branch anyways, there a reason they are bringing for instance the MFD updates sooner.

Note a lot of what will come in 4.0 is also initially being developed on a version of the 3.23 branch. You need to test those elements just the same as SM. It's just that they are not doing that via the tech preview. Not a need. 4.0 first push will be internally to then shift SM to a 4.0 branch and then push a chunk of updates critical so most likely transit and mission side. The other updates for gameplay, locations are all secondary updates. You don't need them for 4.0 in terms of code.

8 to 10 weeks worth of iteration on the systems they have got and then it being pushed to what will make the 4.0 wouldn't be unsurprising considering where tests are at now.
I like to add that many things from 4.0 have been brought forward.

I predict 4.0 to go live on April 25
 
Back
Top Bottom