I am looking to poll Unity inputs over the last several frames and use that data to interpret the user's button presses. From what I've tested however, it feels like polling at the application's 60 FPS framerate leads to some very fast inputs getting missed.
Simple example, user tries to go to Forward from Down:
frame 1 - user is holding Down
frame 1.5 - user taps Forward, but hasn't released Down yet
frame 2 - user lets go of Down and has reached Forward fully
In my current set up, using unity's framerate update, frame 1.5 where the user has both Down and Forward held is missed entirely. Is there a way to run a separate update, that runs at a faster rate than the regular Unity MonoBehaviour Update function? Or would a different solution be needed, such as querying via events(iirc that's an option, but I may be misremembering)?
I don't believe it's possible to decouple polling frequency from frame rate in legacy input system, however in new input system there is a pollingFrequency property that allows you define the frequency in Hertz. It uses a background thread to poll the data. You also need to subscribe to an input action change and record your values there to finally consume them in update method.
Related
I am using ConcatenatingAudioSource in order to play multiple tracks without gaps like this :
player.setAudioSource(ConcatenatingAudioSource(children: [
///some audio sources
]));
If I want now to change the next track to be played, intto a track at an index specified by me, how to do that other than keeping calling player.seekToNext() ?
Is there for example some method like player.setNextTrackIndex(someIndex) ?
p.s. : This question is about just_audio package.
The closest thing to what you're trying to do is:
await player.seek(Duration.zero, trackIndex);
This immediately starts buffering the requested track in order to play it, but there will still be a gap initially while you wait for the audio of that track to buffer. It will be a short gap if the media is stored locally, and a longer gap if the media is accessed over a network.
This is distinct from actual gapless playback which can only happen when the player knows ahead of time which track is next so that it can start buffering it early and avoid the gap. That is, if the user can choose a track at any time, there is no way for the player to predict in advance which track the user will click on next.
Yes, ConcatenatingAudioSource is designed to do gapless playback, but between items that it know are coming next. It is intended to concatenate tracks A,B,C,D together so that there is no gap between A-B, between B-C and between C-D. It can do this because when the player is reaching the end of track A, it knows that B is coming up next and starts buffering B early. Gapless playback doesn't apply to your scenario.
I am new to drools / fusion (7.x) and am not sure how to solve this requirement. Assume I have event objects as Event{long: timestamp, id: string} where id identifies a physical asset (like tractor) and timestamp represents the time the event fired relative to the asset. In my scenario these Events do not arrive in my system in 'real-time', meaning they can be seconds, minutes or even days late. And my rules system needs to monitor multiple assets. Given this, when rules are evaluate the clock needs to be relative to the asset being monitored, it can't be a clock that spans assets.
I'm aware of Pseudo Clock, is there a way to assign Pseudo clocks per Asset?
My assumption is that a clock must always progress forward or temporal functions will not work properly. Take for the example the following scenario:
Fact A for Asset 1 arrive at 1:00 it is inserted into memory and rules fired. Then Fact B arrives for same Asset 1 at 2:00. It too is inserted and rules fired. Now Fact Z arrives for Asset 2 at 1:30 (- 30 minutes from clock). I'm assuming I shouldn't simply progress the clock backwards and evaluate, furthermore I'd want to set the clock back to 2:00 since that was the "latest" data I received. Now assume I am monitoring thousands of assets, all sending data at different times...
The best way I can think to address this is to keep a clock per asset and then save the engine state when each assets data is evaluated. Can individual KieSession's have different clocks, or is it at a container level?
Sample rule: When Fact 1 arrives after Fact 2 for the same Asset.
You're approaching the problem incorrectly. Regardless of whether you're using a realtime or psuedo clock, you're using a clock. You can't say "Fact #1 use clock A, and Fact #2 use clock B."
Instead you should be leveraging the metadata tags for events, specifically the #timestamp tag. This tag indicates to Drools that a specific field inside of the event is actually the timestamp for the Event, rather than the actual time the fact enters working memory.
For example:
import com.example.SampleEvent
declare SampleEvent
#role( event )
// this field is actually in the object, it's not the time the fact was inserted
#timestamp( createdDateTime )
end
Not knowing anything about what your rules are actually doing, the major issue I can foresee here is that if your rules rely on the temporal operators or define an expiry (#expires), they're not going to work and you'll need to redesign them. Especially for expirations: once an event expires, it is removed from working memory; when your out-of-band events come in any previously expired events are already gone and can't be worked against.
Of course that concern would be true regardless of whether you use #timestamp or your original "different psuedo clock" plan. Either way you're going to have to manage the fact that events cannot live forever in working memory -- you will eventually run out of resources and your system will crash. Events must be evicted at some point, so you'll need to design around that in both your models and your rules.
In case of automatic hunting like mobile games, I implemented Auto-combat system in the client, and every single use a skills, the player character's stats are loaded from the server.(like player's attack range)
The tick to use the skill is 0.5 seconds. I thought this was the problem
So I try to build a new one
Load DB at the time the unit is created or specific Event(Join field, Change Channel...) and create an instance for use in Client.
Automatic combat are managed by the server.
I don't know how to do it optimization effectively and prevent Client cheating...
I am looking for a way to make my Unity3D application able to "rollback" to a previous state so that the scene is exactly the same as it was N milliseconds.
For example, say I have a player which has moved forward 5 units. There are objects in the foreground moving around, such as a ball rolling... now imagine that I would like to "undo" 3 moves: the player should appear where he was 3 steps ago and the rolling ball should also move backwards in time.
What approach would I take here? I have thought to create "states", each timestamped with Time.realTimeSinceStartup, but that property is readonly. Alternatively, I thought that I could keep track of frame count, enable V-Synch so that render time is at 30ms, and rollback 30ms * n_frames, but unfortunately, the render time is not constant, even with V-Synch.
Perhaps this is similar to saving the game and then restoring it? However, the save and restore need to be very fast, on the order of less than 10ms.
What are my options here?
I have a simple iPhone game consisting of two "threads": the main game loop where all updating and rendering happen 30 times per second (NSTimer)... and the "thread" that calls the accelerometer delegate 100 times per second. I have a variable "xPosition" that's updated in the accelerometer delegate function and used in the game loop. Is there a possibility of the two "threads" trying to use xPosition at the same time (hence causing a crash or some other problem). If so how can I fix this w/ minimal impact to the game's performance?
I've been using this set-up for many months of development and incremental testing and I've never run into any problems.
Cheers!
If your NSTimer task and your game loop are both run from the main thread you will not encounter any problems with this since only one of them will execute at the same time. Additionally none of them can preempt the other.
However if you are using different threads, you have to be careful when using the xPosition in the game loop since it's value might be updated at any time from the other thread - even though there is only one processor. One simple way of getting past this would be to assign the value of xPosition to a local variable in the game loop and only reference this variable for each run through the loop.
If it's only updated in the accelerometer thread, then there's not much problem. Worst case is that the render thread won't see the change to the data by the accelerometer thread. Since you're running on a single processor, that's not likely to happen. That latter problem can be addressed if you flag the variable as 'volatile' in the source code.