Various bug reports

#1
People, please post if you are able to replicate these bugs/have the same issues; more people suffering from these = higher up the priority list it should go for the devs.

My info:
  • Latest Besiege ver (0.32 I think off the top of my head? - it's from Steam, anyway, and is up to date)
  • Machine is an i7 laptop, 12Gb RAM, loads of free HD space
  • OS is Windows 10
  • Can't post any logs because I'm at work atm, but this isn't a crash report anyway, so don't think you'd get much useful info from those...
  • I can say that although I have some mods installed, none of them are responsible for the below issues (disabled them all & restarted Besiege - got the same problems)

Bug 1: Symmetry plane for swivel joint is offset.

If you choose a swivel joint as the centre block for the symmetry tool, blocks placed higher or lower than the swivel joint have their symmetrical counterparts placed slightly offset. Pretty sure it's only the Y axis that's off, but it could be others (haven't checked)
Bug 2: Symmetry tool doesn't work with delete ('X')

If you delete a block while symmetry is on, the counterpart block on the other side of the symmetry plane isn't deleted. This is really annoying for intricate designs (building rotors with all 3 symmetry planes on means that you have to check in 8 places to find out which block you missed when deleting stuff, instead of just deleting one block and knowing that the other 7 are deleted - this can be a massive pain when you have a lot of overlapping bracing going on and it's difficult to see what is there and what isn't).​

Bug 3: Symmetry tool doesn't always work with braces

Sometimes, when drawing braces with X and Z symmetry turned on, I've noticed that it will only place 3 of the braces, not 4 as expected. It's not due to intersection as far as I can tell, and it only happens occasionally, and I'm unable to figure out what circumstances it occurs in. This is intensely frustrating when trying to build an aircraft where the braces affect the COM. Which leads me to...​

...Bug 4: Ballast weight no longer seems to affect the COM indicator

Changing the ballast weight DOES affect the COM (you can tell it's working when you run the simulation), BUT the blue COM marker/sphere doesn't update/move when you change the ballast's weight, so it's impossible to visually see where the COM is (you have to actually start the simulation to check, then adjust, start sim again etc etc - pain in the ass).

On a similar subject, it would be great to have more than one COM show up for each collection of connected blocks (instead of a global one for ALL blocks placed, even if they aren't connected). E.g. if I build a machine and build a separate target to shoot at that isn't connected to the machine, I'd like to see a COM indicator for the machine and a separate COM indicator for the target. If I positioned 4 separate blocks that aren't connected, I'd like to see 4 COM indicators in the centre of each block, and so on.​

And the biggie that I'm sure you're aware of:

Bug 5: Physics inconsistencies:

There are a number of these, but the big ones that spring to mind are:​

  1. Coaxial rotor designs ALWAYS induce torque on the chassis of a helicopter, no matter how careful you are to make sure that they are all identically built (they SHOULD cancel out perfectly...at least in straight up/down flight anyway. I won't get into the physics of forwards flight here {retreating blade stall etc :p }). You can build the simplest design, then just accelerate it straight up into the sky and you will see this behaviour. I even made sure that the speeds match by using cogs just in case one rotor was slowing down compared to the other - the bug still persisted. I have noticed that ALL rotor designs eventually suffer from Toilet Bowl Effect (google it - look at the RC helicopter forum results) no matter what you do. How bad it is seems to depend on the mass of the rest of the vehicle, and it gets worse the longer the vehicle is in the air.
  2. When building rotors, I've noticed that if you have a fairly long rotor blade design, quite often when the simulation starts the blades will start wobbling up and down ('flapping') of their own accord, and the wobble will INCREASE in amplitude (instead of decreasing to a rest state like it would in real life) until the rotor literally shakes itself apart. Bracing the rotors to each other laterally with ball joints cures this (no idea why - you would expect vertical bracing to improve this, but vertical bracing doesn't seem to change much), but it's really annoying to have to 'fix' something that shouldn't need fixing, resulting in extra weight on your rotor, meaning you need more RPM to get the damn thing off the floor.
  3. Almost all airborne vehicles drift to one side (usually the left for some reason), even when their COM is perfectly central and everything is perfectly symmetric. Again, this gets worse the longer the vehicle is in the air. Landing and taking off again can appear to 'fix' it for small vehicles, but it manifests again after a few minutes.

None of these are fixed by using the 'Accurate Physics' option. I'm guessing that these may be Unity issues, but if there's anything you can do to temporarily fix it until Unity gets fixed, that would be awesome.
Bug 6: Prop & wing lift inaccuracies:

  1. if you create a rotor based around a spinning block with 4 props on it, but rotate the props' orientation through 90 degrees (with 'R') as you place them, you don't get any lift, no matter how fast the spinning block goes. I suspect that what is actually happening is that the prop is now generating a force at 90 degrees to where it should (i.e. forwards/backwards/sideways depending on where it is in the rotation cycle, instead of upwards/downwards depending on direction of spinning block). I haven't double checked, but I don't think this is a problem with wings or wing panels, so there must be some difference between those and props that needs addressing - angle of lift force should be calculated as a function of the prop's angle of attack and the prop's direction of travel, NOT a fixed (and incorrect!) angle relative to orientation of prop.
  2. The amount of lift generated by props, wings, and wing panels seems to be completely unrelated to their wing area: To a beginner, that makes absolutely no sense whatsoever. You would expect the DaVinci wing to create the most lift, followed by the wing panel, followed by the large prop, then the small prop. At the moment the OPPOSITE is true! Yes, this will break some existing aircraft .bsgs if you change it, but so be it. We can deal with it. Also the small and large props seem to generate the same amount of lift as each other (again, counter-intuitive, especially for newbies). I am aware that the props are angled by default and that the wings aren't, but if you angle a wing at the same angle as a prop, the wing still generates less lift.

# 7 (not a bug, but a major annoyance): Pistons

Pistons are too bouncy. They look and behave like suspension blocks, whereas they would be MUCH more useful if they were more like linear actuators, that just don't move (but could break) when force is applied to them. If a player wants a bouncy feel, he can always put a suspension block in, but if he wants a solid linear actuator-type feel, his only option at the moment is to build a large mess of wheels/gears, linkages, and sliders, which is often impractical (e.g. look at the various swash plate/tilting rotor disc helicopter designs - most of them use pistons, but are too bouncy to be of much use; there is no way you could fit four linkage systems in there {without mods, anyway} just to achieve some decent linear motion).​
 
#3
Hey man,

I have some of those issues as well but I have different approach : for some time I've come to think that symmetry issues and few related inconsistencies are maybe intended. Like in reality perfect symmetry doesn't exist so in simulation you have to take this into account. That would be nice to have an answer from someone that actually know the truth but I think it won't happen. Anyway I've few tracks, not any proof but a start that make me believe that theory.

But yeah, that's annoying sometime.

About linear actuators (pistons), here is how I do : tweaked suspension + winches. But it's not usable on everything, it's working better when you can pull rather than when you have to push, and also it's more efficient when you need position accuracy at slow pace (like collective control on helicopters). I can understand that it's frustrating but devs did decide to code the piston like this.

That's a good report you have done, lots of details!
 

ITR

l̺̤͈̘̰̺͉̳͉̖̝̱̻̠̦͈ͅ֍̫̜̥̭͖̱̟̟͉͙̜̰ͅl̺̤͈̘̰̺͉̳͉̖̝̱̻̠̦͈ͅ
Staff member
#4
Hey man, I have some of those issues as well but I have different approach : for some time I've come to think that symmetry issues and few related inconsistencies are maybe intended. Like in reality perfect symmetry doesn't exist so in simulation you have to take this into account. That would be nice to have an answer from someone that actually know the truth but I think it won't happen. Anyway I've few tracks, not any proof but a start that make me believe that theory.
You'd have to ask on a PhysX forum about that, but it's probably just due to floating point imprecisions and how joints work :p
 
Top