Nereid
-
Posts
331 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Nereid
-
-
In the latest patch it seems to be way better now.
-
On 3/2/2024 at 9:35 AM, Dragon1-1 said:
Probably because it's a bug. Fuzing options were introduced recently and the switchology doesn't necessarily work correctly. IRL, if both fuzes are in, if you've got nose or nose/tail armed, you should get instant detonation, while if you've only got tail only, it'll give you delayed detonation. That's the way it should work in DCS, too.
I would tend to agree.
-
1
-
-
17 hours ago, Holbeach said:
Not exactly a bug, but only one fuse can be used per bomb, timed at one end and plugged at the other to make it work correctly.
Then again the question remains unanswered: Why does an unarmed fuse detonate the bomb if two fues are used but not if one fuse is used? And we do have the option to use two fuses (that is undenyable).
17 hours ago, Holbeach said:This means you could have a different time on each bomb, if you so desired.
This has nothing todo with head or tail fuses
-
1
-
-
Just now, Tholozor said:
Already reported:
Ah. Thanks. Let's hope they fix it soon. This oscillation makes any targeting in the C/PG seat nearly impossible.
-
I was switching from pilot to G/CP and ordered George (as a pilot then) to hover. But he fails to hold a steady heading to the target completely. Every few seconds he rotates to the right about 15 to 20 degrees and is then comming back, only to start his rotation to the right again.
Even I with my limited skills in a hover would do this better - especially with ATT hold on.
EDIT: I have uploaded a TRK-File. It was easy to reproduce.
The mission starts in the air so I had to get into a stable hover first. This was done at 05:31:20, heading 30°. I was holding this heading for about 15 seconds and then I switched to C/PG. George took over and at 05:32:00 he had quite a lot problems to hold a constant heading.
There is A LOT room for improvement I would say.
-
On 1/27/2024 at 6:56 PM, ac5 said:
and still radio silence from Manston, Ugra and ED...
They will have do redo it anyway when the new ATC comes out. So maybe it's not worth the time to analyze and fix this.Well, I'm a developer myself and maybe I wouldn't try to fix the problem either. But a few words about it would be nice.
-
ATC will send you to the wrong direction too. I you follow its orders you will takeoff with the wind instead against it. At least on Ford it does it this way.
-
Is the ATC not choosinbg the runway depending on wind direction?
I'm at Ford, Parking lot 2, wind comes from 41° (7 m/s) and ATC sends me to runway 23. I would say runway 05 would be the better choice.
-
57 minutes ago, Bozon said:
That has to be a bug.
I tend to agree. If not there is a detailed explanation neccessary in the manual.
And if I remeber it correctly the default is 0 seconds for both fuses and both are installed by default. If you change just one of them and deliver them low, it will be a nasty surprise...
-
1 hour ago, Holbeach said:
From a game point of view, that is what you would expect, but the nose fuse has no effect.
Only the tail fuse actually works.
So the tail fuse is armed when the nose fuse is armed? Because the bomb detonates with a unarmed tail fuse too... And THAT was my question.
-
1
-
-
20 hours ago, peachmonkey said:
you're supposed to use only 1 fuse, either tail or the nose one. Not both. If you're using the nose one then set the tail one as 'plugged' and vice versa.
So as Bozon asked: Why is there a nose/tail fusing selector in the panel? Why does an unarmed fuse cause a detonation? Then an unarmed nose fuse wiithout a tail fuse should detonate too. Or does the nose/tail selector arms both fuses and is there just for eye candy?
Don't get me wrong: Maybe it worked that way for some strange reasons. But chances are it is just wrong.
-
I was testing fuse delays on 500 lb short tails and set the nose fuse to 11 and the tail fuse to 0 seconds. I though if I just arm the nose fuse in the cockpit the bomb would detonate 11 seconds after impact because of the delay of the nose fuse the tail fuse isn't armed. But it detonates instantly after impact. Is this correct or a bug? If I set both fuses to 11 seconds the delay works.
And was does "plugged" mean for a fuse? No fuse? -
Indeed. I was using Manston as a training base for landings in my missions and this drove me nuts. I spend over an hour to get it to work (which I did by choosing another airfield) and after all it's a bug in the map.
Some other airfields do work.
-
On 12/21/2023 at 12:14 AM, pii said:
Why aren't you using MT exe? You would have MUCH better performance. It's also needed to get the new landing animations where the helo kicks up dust and blows the grass and trees around.
Because it wasn't working so well in some aspects and still isn't. Just today DCS was completely unresponsive in MT for no obvious reason until I restarted my whole system. The performance in flights without many AI units isn't that much better in my experience either. I'm still changing between ST and MT sometimes. And in MT we still get stuttering every then and now (even on my rig with 64 GB of RAM and a RTX 3070). This is not the case in ST (and one of my biggest complaints about MT).
Currently I'm using MT - until the stuttering bothers me too much.
-
Just to check DLAA I have tested the current (rather old) update in multithreading and there was no drift in ATT Hold. It worked like a charm - and as bradmick said "rock solid". In my last flight a few weeks ago before the last update it didn't work and always crashed me but I was using the single threaded binary. Maybe there is a difference between ST and MT?
But it was a short flight in my test. So, maybe the issue is still there even in MT.
BTW: I got only 40 fps in DLAA and my graphics card was at 90% but it felt extremely smooth and controllable - even without any practise for weeks. Unfortunately my time is a bit limited at the moment.
-
22 hours ago, comcat said:
It's so bad. how can you brake something that was working so bad. UPdate? no- Downdate!!!
This is quite common in software development. Often things depend on each other. A fix here, another issue there. Sometimes the new issue is overlooked.
But ATT mode works that bad (at least for me), it is really hard to overlook.
-
1
-
-
On 10/26/2023 at 1:25 PM, lee1hy said:
Hovering is now possible without ATT mode.
Unfortunately ATT mode seems to be broken now. I doesn't work for me at all before and after the last patch. But this is another topic.
-
3 hours ago, AndreNL said:
I started this topic to see if I am the only pilot who has this problem, and if not, it is a signal to the designers to address these problems in their work.
You are not alone. I'm facing the some problem even with the latest patch. Lets hope they will improve this soon.
But cudos to them for fixing the replays when flying helicopters.
-
1
-
-
1 hour ago, Despayre said:
Who do I report this to?
My car doesn't teleport... obviously, since it was never a feature, it's a bug. I'd like it fixed.
A car is never supposed to "teleport". So this is a "feature request" and not a bug. But if your car misses an option to refuel - even your local seller never said it could be refuelled - it is a bug.
So your answer is the well known category of "silly nonsense".
You may now try to claim that a DCS modules doesn't have to have a keybinding for every switch, dial, ... But then you would not be taken seriously here in any way. Feel free to choose...
And to give you an example why your and draconus answer is silly: There is currently a bug report that "Flight controls freeze during CAT launch". But by your logic, because it's beta and there was never a word that they should not freeze in that situation, it is not a bug. Bugs are common and acceptable in beta and early access. But claiming such things are not bugs is just silly.
-
7 hours ago, draconus said:
And then they removed it? When?
No. They do not have to be removed. As I said: Overlooked. Please read more carefully.
7 hours ago, Lt_Jaeger said:Are you guys done yet?
Draconus chose to give silly answers. But yes, post 6 is the solution.
-
55 minutes ago, draconus said:
No, a bug is a mistake in programming.
And to prove you wrong and to show that you do not have any clue what you are talking about: There are other kinds of "bugs" that are not "mistakes in programming"
1. Configuration / data errors. There may be initial data in a database or file that leads to unexpected/wrong behavior of an application. But no "progamming error" was made. Or the database itself is not configured properly for the running application. Or the underlying OS is not configured properly for the running application or database or middleware or whatever (kernel parameters, limits,...). Remember: In the industry an application is often coupled with the underlying OS and the customer isn't responsible for the OS at all.
2. Lack of hardware ressources. The sold hardware (in the industry software is often coupled with hardware) is not able to run the software on the customer site on real world loads.
3. "Broken by design". The software architect did some mistakes so that the software is not working properly on real world loads. But there was absolutely no "programming error". (choosing the "wrong" database, programming language, algorithms, middleware, hardware, ...)
etc. (there are even more categories; some "bugs" are really strange ones that do not fit easily in any category and are a category "by their own" without any "programming error")
We are at least facing option 1 here .
-
1 hour ago, draconus said:
No, a bug is a mistake in programming.
LOL. This is nonsense again. You are not working in the software industry, are you?
1 hour ago, draconus said:Something that was written, added or implemented but is not functioning properly, different than intended or not working at all.
It was written and it is NOT working properly. There is a keybinding missing.
1 hour ago, draconus said:If the binding was never added it can't be a bug
This is nonsense. Then no overlooked part of a feature could be a bug.
1 hour ago, draconus said:I already linked the thread with many "overlooked" bindings if you think that way.
I already gave you the link to a dictionary for the word "request". Which word of that dictionary you did not understand?
-
36 minutes ago, draconus said:
If it was added by a programmer before but not working correctly now - it'd be a bug.
This is again nonsense. A missing feature that should be in place is a bug.
36 minutes ago, draconus said:When the feature was never added -
The feature was added. Keybindings are there but some were OVERLOOKED. Overlooked parts of a feature are bugs. [even incomplete or missing features are bugs by some definitions and such bugs are to be expected in beta/EA, but this is not the topic]
-
On 7/15/2023 at 9:05 PM, draconus said:
It's a missing feature in early access module. It's not a bug by any definition.
This is nonsense. If there is a keybinding missing then it IS a bug by EVERY definition.
Apache (George Pilot) ability to steady hover is very poor
in Bugs and Problems
Posted
Just tested. It is working fine for me. It took about a second to get control and it was not as chaotic as it was a few months ago. Even with wind. I was quite surprised that I did not struggle at all, because I was expecting a bit of a struggle. And there was no need to reset the trim either.
But I'm not playing DCS that often at the moment. So maybe I was just lucky.