Not a member yet? Why not Sign up today
Create an account  

  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 
Two small propulsion-related suggestions/fixes

#1
I'm going to bang on about number 1 until it's fixed Tongue I'm not 100% sure they're bugs, hence they're in here.

* Stop changes in number of wheels( from damage or repair ) resetting craft speed to 0.

And this one is a bit odd -

* If an ACB tries to reduce the value of a drive maintainer via CC input, it instantly resets the maintainer to zero. This doesn't happen via keyboard CC input, so I can't imagine it's intended. Please let ACBs decrement drive maintainers properly.
Poke my boat! mostly pre-2.0 learning & catalogue thread - Update: Heavy & light tanks 07/04/18 for 2.1. 6 ships made 2.0 aware. No more post-processing! finally! but now I can't read the forum.
Reply

#2
(2018-03-19, 02:15 PM)Richard Dastardly Wrote: I'm going to bang on about number 1 until it's fixed Tongue I'm not 100% sure they're bugs, hence they're in here.

* Stop changes in number of wheels( from damage or repair ) resetting craft speed to 0.
This may be hard to fix, when there's a change in the vehicle (blocks added/removed or repaired/destroyed), some things are reset.
For example, when an AI block is added, all AI blocks are re-processed in order to reconnect them to their mainframe (because the connection may have changed due to the newly added block).

I'm not sure how it is done for wheels, but it seems to be something like that, and it may not be easy to fix.


(2018-03-19, 02:15 PM)Richard Dastardly Wrote: And this one is a bit odd -

* If an ACB tries to reduce the value of a drive maintainer via CC input, it instantly resets the maintainer to zero. This doesn't happen via keyboard CC input, so I can't imagine it's intended. Please let ACBs decrement drive maintainers properly.

I'm not very used to the drive maintainer, in fact I've never used it... Do you have a small blueprint that reproduce the problem?
Reply

#3
(2018-03-19, 05:43 PM)Gladyon Wrote: This may be hard to fix, when there's a change in the vehicle (blocks added/removed or repaired/destroyed), some things are reset.
For example, when an AI block is added, all AI blocks are re-processed in order to reconnect them to their mainframe (because the connection may have changed due to the newly added block).

I'm not sure how it is done for wheels, but it seems to be something like that, and it may not be easy to fix.

Yeah, I'm thinking the wheel manager has to reset it's list of wheel choices - but it's literally murderous to AoTE, tanks stopping moving all the time will just get wrecked - & really can't be left as is. Wheels are fragile enough to get taken out by random frag hits, or not-that-nearby HE bursts, so you can imagine how often the number changes.

(2018-03-19, 05:43 PM)Gladyon Wrote: I'm not very used to the drive maintainer, in fact I've never used it... Do you have a small blueprint that reproduce the problem?

I basically took a usual ACB-controlled tank & set the CC inputs to seperate left & right drive maintainers instead of directly to the wheels though. Drive maintainer gradually builds value upwards like it's meant to, until it's asked to reduce value and then it zero's out in one go.

Will insert a bp below tomorrow.

Edit: BP attached. The spinblock stuff is just to get a visual idea of what the AI is doing. Stick the vehicle in fleetmove or patrol mode & have it drive around, you can watch the hand on top of the drive maintainer to see roughly what it's value is.

I think the maintainer might be going into reverse slightly, actually - either way it still wipes it's value instantly.


Attached Files
.blueprint   Maintainersteer.blueprint (Size: 44.85 KB / Downloads: 6)
Poke my boat! mostly pre-2.0 learning & catalogue thread - Update: Heavy & light tanks 07/04/18 for 2.1. 6 ships made 2.0 aware. No more post-processing! finally! but now I can't read the forum.
Reply

#4
I don't think it's linked to the ACB.
The ACB is just issuing the commands exactly as the keys, the code is the same.

And I reproduced it with the keys and your blueprint.
It's just a matter of pressing several keys at the same time (to simulate the fact that the ACBs are sending the commands simultaneously).
Try pressing 'T' and 'Y' simultaneously and continuously when in 'COMBAT' mode, then, shile still pressing 'T', switch the 'Y' key to the 'I' key,
You will see the drive maintainers needles jump to 0.

I will try to find out where the problem is, but as I don't really know how the drive maintainer works (or even what it does...) I may have some trouble.


As for the wheels, I have added it to my todo list, I hope that it will be fixable.
Reply

#5
OK, I spent some time looking at the drive maintainer.
2 things:
- the needle is not well centered (make it go at max, and then at min, and you'll see that it's not well centered), can you confirm it (it may be on purpose, in which case I must not fix it)
- the 'reset to 0' feature has been implemented on purpose

The 'reset to 0' feature is kicked in when there's a change of the sign of the input to the drive maintainer.
Just replace the wheel on the initial raft with a complex controller, place a drive maintainer anywhere and configure 'T' as positive and 'G' as negative and you can see the problem.
.blueprint   raft.blueprint (Size: 48.78 KB / Downloads: 7)
- when you keep pressing 'T', release it (and wait some time, 0.1s is enough) and then keep pressing 'G', you have the behavior you want
- when you keep pressing 'T', and then keep pressing 'G' without releasing 'T', you see the 'reset to 0' feature in action.

As anticipated it had nothing to do with ACBs, but it is a drive maintainer thing.
I have no idea why it has been intentionally coded like that, there's probably a reason.
But one thing is sure, it is not a bug, it is intentional, there is an explicit check for the case where the sign is the opposite of the sign in the previous frame, and in this case the drive maintainer is reset to 0.

As I said, I'm not familiar with the drive maintainer, so I do not know if there are some situation where it must be reset when the input sign is reversed between 2 frames.
If there are no such situation, then it's very easy to fix.
Reply

#6
About the wheels, I took a look, and each time a wheel is added/removed/repaired/destroyed then all the wheels are regenerated, I'm not 100% sure but I think that the fact to regenerate a Unity wheel will stop it (as it will be spawned with 0 rotation velocity).

As I said, it won't be an easy one to fix...
Reply

#7
What happens if not all wheels are regenerated?
From the Depths english playlist starts here, before that it's hungarian:
https://youtu.be/Ltdx0yVI9cA?list=PLImar...ZokVtdBa73
MULTIPLAYER!

[Image: 6yFiDvF.jpg]
Reply

#8
(2018-03-20, 01:50 PM)Normal69 Wrote: What happens if not all wheels are regenerated?

The problem is that at that point we have forgotten which wheel was already there or not.
It's all or none, and if no wheel is generated then there's no wheel.

We would have to find a way to know which wheel haven't been modified and not regenerate them, but it's a lot easier said than done.
Reply

#9
(2018-03-20, 09:47 AM)Gladyon Wrote: OK, I spent some time looking at the drive maintainer.
2 things:
- the needle is not well centered (make it go at max, and then at min, and you'll see that it's not well centered), can you confirm it (it may be on purpose, in which case I must not fix it)
- the 'reset to 0' feature has been implemented on purpose

The 'reset to 0' feature is kicked in when there's a change of the sign of the input to the drive maintainer.
Just replace the wheel on the initial raft with a complex controller, place a drive maintainer anywhere and configure 'T' as positive and 'G' as negative and you can see the problem.
- when you keep pressing 'T', release it (and wait some time, 0.1s is enough) and then keep pressing 'G', you have the behavior you want
- when you keep pressing 'T', and then keep pressing 'G' without releasing 'T', you see the 'reset to 0' feature in action.

As anticipated it had nothing to do with ACBs, but it is a drive maintainer thing.
I have no idea why it has been intentionally coded like that, there's probably a reason.
But one thing is sure, it is not a bug, it is intentional, there is an explicit check for the case where the sign is the opposite of the sign in the previous frame, and in this case the drive maintainer is reset to 0.

As I said, I'm not familiar with the drive maintainer, so I do not know if there are some situation where it must be reset when the input sign is reversed between 2 frames.
If there are no such situation, then it's very easy to fix.

Fairly sure the maintainer model animation is just meant to be "this has a non-zero value". I've never really paid any attention to it's actual position, can't imagine what would be hurt by fixing it ( it may be the animation that's off-centre, of course ).

Presumably +&- together is meant to be T+G reset like normal controls? I wonder if changing the check to "must be + & - together for 1s" or other period of time would work. Thing is, that doesn't actually reset to 0 anyway!

As for wheels - is there no master list of wheel spots in the construct somewhere?
Poke my boat! mostly pre-2.0 learning & catalogue thread - Update: Heavy & light tanks 07/04/18 for 2.1. 6 ships made 2.0 aware. No more post-processing! finally! but now I can't read the forum.
Reply

#10
(2018-03-20, 03:35 PM)Richard Dastardly Wrote: Presumably +&- together is meant to be T+G reset like normal controls? I wonder if changing the check to "must be + & - together for 1s" or other period of time would work. Thing is, that doesn't actually reset to 0 anyway!
It works like that for all keys, not just 'T' and 'G'.
I have no idea why this piece of code has been written, it may be used to fix a bug or prevent a problem.
I need the history of the project in order to avoid breaking something, so I'll see with Nick when he comes back.


(2018-03-20, 03:35 PM)Richard Dastardly Wrote: As for wheels - is there no master list of wheel spots in the construct somewhere?
There is, but it contains the newly added wheel, and the newly added wheel needs to be reconstructed but not the other ones.
As soon as Nick is reachable I'll see that with him.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)