Add option to have component collisions turned back on

[Internetzspacezshipz]

Is your feature request related to a problem? Please describe. I'm not a huge fan of the recent change to turn off collision for components, and I am not sure if this is a permanent change or just a temporary one. If it is permanent, would it be possible to have an option to turn it back on? I really enjoyed trying to figure out the best layout for my vehicle internals, and where I should be placing certain part. With this recent change to have parts not intersect with armor or baskets, I find it to somewhat defeat the fun of placement of internal parts, since it is so forgiving now.

Describe the solution you'd like An option to turn collision of component placement with armor and turret baskets back on.

[robotnikthingy]

I also feel the same. Its amazing that we now don't have to worry about holes for our turrets, but removing collisions with armor for crews, engines, etc, removes a lot of the fun and challenge, like having to balance armor thickness and crew space.

[ColsonThePCMechanic]

Having this lack of collision be optional - or have a method of highlighting where cuts are made - would probably be a good idea. I'm not the only one who originally thought this was a glitch, and I'd at least like to know that objects are clipping into the armor and where it's at.

[Internetzspacezshipz]

I also just realized that this will make it more difficult to work on and judge design competitions, since competitors could clip things into each other on purpose, or even without realizing, and it might not always be obvious. Eg. clipping fuel tanks, ammo, crew members, etc through the turret basket or through armor, which might give an unfair advantage to those given players, whether they realize it or not.

[Muushy]

Open to bringing it back as a difficulty option.

I don't see how this has an impact over the challenge of fitting everything in the vehicle, other than making it less fiddly. Armour thickness does still absolutely limit crew space. As far as I'm aware, it adds no advantage that couldn't be achieved with plate collisions turned on and enough effort.

Disabling plate obstructions also solves the applique armour issue. That is, how to make parts like mantlets add armour without having to tailor them to where they're being placed. Otherwise cannon rotation arcs would have to fit entirely within the hollow area in the mantlet's base. Requiring mantlet bases to be shortened, reducing their versatility.

Clip warnings would be a good idea.

[Internetzspacezshipz]

The problem I see with the mantlets having obstructions off is that gun breaches already have collision with armor meshes, so without cutting a hole for the mantlet to fit into, you're probably going to run into the breach colliding with things anyway. I do wonder if there are other routes to make the mantlets work? I can imagine a system similar to how the engines and transmissions get more segments, so perhaps it would be possible to have adjustable mantlet base lengths so that players could make them longer or shorter as needed... I might be biased on this second thought as a long time player who enjoys more simulator-y behaviours; but perhaps making mantlets a part of the armor system more directly. By this I mean creating mantlets with the freeform armor system, allowing players to adjust their shape after they have been placed. Basically the list of current mantlets become "template" freeform meshes that can be placed and used as they used to, but then also allow the player to make adjustments to the shape to fit biggers guns, more armor, etc.

Also separately from all this mantlet talk, I think that clipping objects such as ~ammo, fuel, or~ crew into armor is problematic because it might allow those parts to become effectively invulnerable.

Example of an invulnerable crewmember: (yes, he looks like he's trapped in carbonite lol)

I was also going to show a case for ammoracks and fuel as well, but it seems that ammoracks have different penetration logic to them (probably because they are simple rectangular prisms as opposed to posable meshes). Even if they are encased in a big brick of armor, the armor value will only be the distance from the surface of the armor to the start of the ammo, which is fair (although now I am scared that there will be armor mass that is essentially wasted).

I also just realized another issue with this setup is that if someone makes a tank with a turret that has no turret "hole", then penetrations of the turret or of the hull will not allow fragmentation to pass through into the hull, which could lead to unexpected damage mechanics, especially when APHE gets added back in the future and fragmentation is a larger part of the equation.

Perhaps another option entirely is to do literal boolean operations on the mesh(es) when doing intersections with the freeform meshes. This would make turret baskets and non-custom mantlets much easier, and could also make it easier to do freeform modelling if exposed in a more generic fashion to the user. This would also solve the issue I mentioned above, with the fragmentation not passing from turret to hull, since the hole would actually be there. It would also mean that the hole from the turret would not contribute to the mass of the vehicle.

To make this even longer and state something else, I just feel like the game has already come this far in making so many things realistic, it feels like we're backtracking, and almost making geometric internals less important. And yeah, I get it, releases have to be made (am a game dev myself, I know the struggle to release stuff), but it does feel like we're losing part of what made the geometric internals so awesome in the first place! Sorry to post so much stuff, and I hope I don't come off as "entitled" or anything. I'm just really passionate about this game and want to see it be the best it can be!

PS. clipping warnings would be a good solution too, since that way at least it's optional to players to determine for themselves whether that's something they want to worry about or not. If doing design competitions, the rules could say "clip warnings = disqualified" or something along those lines as well for more restrictive competitions.

[HomelessDumpster]

I feel like the hull shouldn't have clipping disabled but only the turret. For the turret it makes sense since it would collide with the hull roof otherwise. But why do the things inside the hull also have collision disabled?

If it's because of casemates coudln't we just get a "ignore collisions" button for every model to infividually use them? That would be way better IMO.

Also can cheats and stuff please only apply to tanks and not the game in general?

[ColsonThePCMechanic]

To make this even longer and state something else, I just feel like the game has already come this far in making so many things realistic, it feels like we're backtracking, and almost making geometric internals less important. And yeah, I get it, releases have to be made (am a game dev myself, I know the struggle to release stuff), but it does feel like we're losing part of what made the geometric internals so awesome in the first place!

Honestly a good point, it feels quite off to allow clipping in a way similar to 0.127. It does remove alot of the whole point of the update.

[robotnikthingy]

I don't see how this has an impact over the challenge of fitting everything in the vehicle, other than making it less fiddly. Armour thickness does still absolutely limit crew space. As far as I'm aware, it adds no advantage that couldn't be achieved with plate collisions turned on and enough effort.

Maybe I'm missing some info here, but I'm not sure how armor thickness limits crew space in the current build, since crew can be clipped into the armor with no downsides. Unless currently the parts of the crew clipped into the armor subtracts from the armor.

Overall I think your proposals make sense, and being able to place mantlets and turrets (and I'm guessing other parts in the future) without making any holes greatly helps with building tanks. But disabling collisions between armor and crew seems like something that should be re-enabled imo, as others mentions it seems to remove some of the point of geometric internals (at least regarding the crew, seems like fuel, engines and ammo will work fine with the current system)

[ColsonThePCMechanic]

It was mentioned that one reason for the change was due to finger positions invalidating a build. Maybe just change the hitbox to only include the palms of hands?

[HomelessDumpster]

Re-enabling collision between aemour and crew would bring the need to make holes back. Thats why I suggested removing collision only for turrets or having a opptional remove collision button for each module

[Internetzspacezshipz]

It was mentioned that one reason for the change was due to finger positions invalidating a build. Maybe just change the hitbox to only include the palms of hands?

This is a part where I am in the opinion that perhaps breaking vehicle designs isn't a problem? I say this because this is literally an alpha inside of an alpha game, so version to version compatiblity shouldn't be a huge concern yet (imo). Maybe once the game is officially in beta, it becomes a more pressing issue. I'm not saying that it should be "0.2.14 vehicles absolutely cannot be loaded into 0.2.15" since I assume that 99% of the save file is the same. Rather, that it's okay if the parts inside the vehicles now are in invalid positions and clip into things, and the player has to shift them around again to make them fit. Totally cool with that.

On another note, perhaps I am in the minority here, but I don't even think it's important to make pre-0.2 vehicle designs compatible with geometric internals. I mainly say this because there is simply no comparison between pre-geo-internals and geo-internals. It has become a completely different game, so it seems counterproductive to me to fully support pre-0.2 vehicles. I assume it wouldn't be a big undertaking to at least import the armor meshes though, since they inherently have a similar structure to 0.2 vehicle armor (being made up of positions and armor thickness values).

These both might be controversial takes, but I personally don't even remember a fraction of the vehicles I made pre-0.2... The ones that I did really like, I have already recreated in 0.2 anyway, and with much better quality since I have more experience now.

[Muushy]

Colson was referring to a comment I made about the silliness of a millimetre difference in finger position invalidating the entire crewmember's position.

The change is the most simple fix for these issues:

• Making crew valid placement less black and white. I don't think placement of any other part was problematic.
• Removing the need to create and manage geometric holes for turrets and cupolas.
• Preventing attached part armour from needing to be tailored to the surface it's placed on.

It doesn't feel polished, which I don't like. Though that could be helped by outlined clip warnings.

Holes Portals were done up until 0.2 and maybe it was just my implementation, but they vastly complicated the damage model and weren't very predictable in practice due to being invisible to the player. They required a shader trick to create a hole in the turret. Hacky in almost every area.

Geometric holes are the simple and perfect solution from a technical perspective, but the creation and management of the hole geometry is a lot to expect from the player. Could be made easier with prefab freeform structures but it will still be troublesome with holes on curved surfaces. Mesh Booleans get rid of these downsides, but are a tough one to implement and I'd probably have to rework plate generation to support n-gons. Could run into trouble of plate structures getting lost entirely in the Booleans.

Greying crew member obstruction Switching over to a voxel based system could work. Mark voxels containing armour or a part. Then search outwards to a limit from key crew member positions like the head, hands, feet, etc. This'll give an idea on how much free space the crew member has. If cupolas and turret rings then unmarked all armour voxels in certain volumes, it'd allow crew members to poke through any armour inside turret rings and cupolas.

A voxel map is pretty inevitable anyway for simulating pressure/fire in the damage model. Turrets and cannons could also rotate this voxel field until they meet voxels from another structure to find rotation limits.

Preserving prefabricated attached part armour Can't think of any other solutions for this other than the one in 0.2.14. Any solution in mind would require these to be editable.

All in all, a mountain of extra work to pursue other solutions.

[Muushy]

Maybe I'm missing some info here, but I'm not sure how armor thickness limits crew space in the current build, since crew can be clipped into the armor with no downsides. Unless currently the parts of the crew clipped into the armor subtracts from the armor.

Armour overlapped by a part is discarded by the damage model and its mass is still counted.

[ColsonThePCMechanic]

Outlined clip warnings would probably be the simplest solution to improve upon the object placement system.

[HomelessDumpster]

Colson was referring to a comment I made about the silliness of a millimetre difference in finger position invalidating the entire crewmember's position.

The change is the most simple fix for these issues:

* Making crew valid placement less black and white. I don't think placement of any other part was problematic.

* Removing the need to create and manage geometric holes for turrets and cupolas.

* Preventing attached part armour from needing to be tailored to the surface it's placed on.

It doesn't feel polished, which I don't like. Though that could be helped by outlined clip warnings.

Holes Portals were done up until 0.2 and maybe it was just my implementation, but they vastly complicated the damage model and weren't very predictable in practice due to being invisible to the player. They required a shader trick to create a hole in the turret. Hacky in almost every area.

Geometric holes are the simple and perfect solution from a technical perspective, but the creation and management of the hole geometry is a lot to expect from the player. Could be made easier with prefab freeform structures but it will still be troublesome with holes on curved surfaces. Mesh Booleans get rid of these downsides, but are a tough one to implement and I'd probably have to rework plate generation to support n-gons. Could run into trouble of plate structures getting lost entirely in the Booleans.

Greying crew member obstruction Switching over to a voxel based system could work. Mark voxels containing armour or a part. Then search outwards to a limit from key crew member positions like the head, hands, feet, etc. This'll give an idea on how much free space the crew member has. If cupolas and turret rings then unmarked all armour voxels in certain volumes, it'd allow crew members to poke through any armour inside turret rings and cupolas.

A voxel map is pretty inevitable anyway for simulating pressure/fire in the damage model. Turrets and cannons could also rotate this voxel field until they meet voxels from another structure to find rotation limits.

Preserving prefabricated attached part armour Can't think of any other solutions for this other than the one in 0.2.14. Any solution in mind would require these to be editable.

All in all, a mountain of extra work to pursue other solutions.

So I have a few questions if you don't mind answering them.

1. Why can't we just have holes but without geometry? Kinda like a decal that removes collision for the face it's placed on. WOuld that be a possible solution? It would make management a non issue
2. What if holes were just a plate (so 4 points) and the roundness was just a decal?
3. what if holes would add a square around it so they wouldn't mess with the entire roof.
4. Would it be possible to have collision removed for only guns and parts within a turret? This should be a good solution IMO since it would only affect turrets
5. Will you try improving on holes and their creation to make this (honestly pretty stopgap feeling) non important since the issues would be fixed otherwise?

[HomelessDumpster]

I honestly hope we can have a better solution for these problems than just removing collision in the future

[Muushy]

So I have a few questions if you don't mind answering them.

1. Why can't we just have holes but without geometry? Kinda like a decal that removes collision for the face it's placed on. WOuld that be a possible solution? It would make management a non issue
2. What if holes were just a plate (so 4 points) and the roundness was just a decal?
3. what if holes would add a square around it so they wouldn't mess with the entire roof.
4. Would it be possible to have collision removed for only guns and parts within a turret? This should be a good solution IMO since it would only affect turrets
5. Will you try improving on holes and their creation to make this (honestly pretty stopgap feeling) non important since the issues would be fixed otherwise?

1. This is the described "Portals" approach.
2. This is the described prefab freeform structures. It struggles with holes on curved surfaces.
3. Sorry not sure I follow.
4. I don't see how this solves any of the issues.
5. Sorry, I don't understand the question.

[HomelessDumpster]

3. Sorry not sure I follow.

Basically just have the hole be on a seperate plate or face so that there would be only 4 points of connection to the rest of the hull instead of the 8 or something the hole has

5. Sorry, I don't understand the question.

Yeah sorry my writing was bad. I was asking if you would keep improving or trying to improve upon the hole creation system so that the portal approach or non collision approach would not be necessary in the future since holes would just be easy to do

[Internetzspacezshipz]

All in all, a mountain of extra work to pursue other solutions.

Yeah, sadly some stuff is a bit out of reach for a single developer in a reasonable timeframe, and I totally get that. I heard somewhere that at some point you'll be hiring some help. I know there are probably a fair number of game programmers in the community who would love to work on this sort of game. I, for one, would love to set up a system for mesh booleans.

I was thinking through this further, and really I think it would be optimal to go with a two-model system, where you have:

1. The base model, which contains the player placed verts/tris, and also the player created boolean models/shapes. This is the model that is saved to disk.
2. The "solved" model, which is calculated at runtime by solving the boolean logic for all of the mesh.

I now realize doing this could also help more accurately solve the armor mass problem, since you would have the end product solid mesh. You could then use this algorithm to find the total volume of the armor, and then multiply it with the density of the armor to find the mass.

By doing it this way, the player could always go back and non-destructively move the boolean around the model, rather than having the boolean logic be a permanent change to the model. This would be a better workflow from the player's perspective. I cannot tell you how completely incredible something like this would be for cutting things like view ports, turret holes, exhaust cutouts, radiator vents, etc etc. It could also be used for existing 3d model assets already in the game, since it would just be a matter of adding those models into the mesh before it gets converted to the output mesh.

And again, yeah, this is a complex and time consuming solution to implement... But getting one or two additional programmers to work on the project would make something like this totally within reach. After all, the difference between 1 and 2 is double the output, 1 and 3 is triple the output, etc... (ofc this is oversimplifying things) Just having another person or two could make an absolutely massive difference in timeframes and what can reasonably be expected regardless. Anyway, I hope I am not out of line by suggesting these things, since I am sure you hear all the 50,000,000 suggestions all the time from the community, and this is yet another one (or two). I just want to see Sprocket do well and be the best game it possibly can be.

[AoKishuba]

I bought this game because I heard somebody had finally gotten around to making a vehicle designer which

1. Focused on realism and geometric design
2. Didn't use voxels

I'd been playing for a few days when this update came out, and it was so directly contrary to everything I'd learned about the game that I assumed I'd misread. I can't speak too much from a technical perspective (I don't follow the discussion about mantlets above--seemed like they were working just fine in the update before this one?), but this change had a huge impact on the feel of the game for me.

I have zero problem with these things being fiddly. That's how design works. I'm manually laying out holes for the turret for weight savings and realism regardless, and agree with the poster above who said that clipping feels at odds with the idea of needing to skillfully place components.

A system for indicating clipping, identical to the current one (with outlines and a list of clipped objects in the part description, but with yellow highlights instead of red) is definitely needed to make this workable if it is kept, but ideally that should be a pretty big "if".

[ColsonThePCMechanic]

I would assume Hamish tackles this during the beta phase.