I'm creating a bukkit plugin and it requires lighting to be added and I want to be able to accomplish this server side only so that users don't need special plugins to see the lighting. Could this be done? If I'm not mistaken rendering lighting has been server side before? I would also like this lighting to be colored and lighting sources to be invisible (lighting from coordinates is acceptable since the map will be set)
My fear, can it be done?
You could do this using:
p.sendBlockChange(Location, Material, Byte);
Location is the location of the block
Material is the material that you want the player to see
the Byte is the data, so in the block 43:8, you would use 8. If there is none, just use 0.
So, you could do this to send the block update to all players:
Location[] invisibleBlocks; //all Invisible locations
for(Player p : Bukkit.getOnlinePlayers()){ //get all online players
for(Location l : invisibleBlocks){ //get all invisible blocks
p.sendBlockChange(l, Material.AIR, 0); //send block change of AIR to the player
}
}
The only problem is that block changes get reset when a player unloads/loads the chunk that the change is in. So, to fix this, you could schedule a timer:
Location[] invisibleBlocks; //set this to the locations of all of the blocks you want to make invisible
plugin.getServer().getScheduler().scheduleSyncDelayedTask(plugin, new Runnable(){
public void run(){
for(Player p : Bukkit.getOnlinePlayers()){ //get all online players
for(Location l : invisibleBlocks){ //get all invisible blocks
p.sendBlockChange(l, Material.AIR, 0); //send block change of AIR to the player
}
}
}
},100);//delay time is 5 seconds (5 seconds * 20 ticks per second)
Then all you need to do is put glowstone in the the invisibleBlocks locations, and it will appear as air, but (should) still emit light.
One problem with this is that if a player tries to walk into the block, they will walk in half way, then get teleported back out. This is because the client thinks there isn't a block there, yet the server knows that there is, and when the player walks into the block, the server teleports them back out, making a jerky kind of motion.
If you put this somewhere where players can't walk into it, you should be good!
Related
I’m manually writing a video recorder. Unfortunately it’s necessary if you want to record video and use ARKit at the same time. I’ve got most of it figured out, but now I need to optimize it a bit because my phone gets pretty hot running ARKit, Vision and this recorder all at once.
To make the recorder, you need to use an AVAssetWriter with an AVAssetWriterInput (and AVAssetWriterInputPixelBufferAdaptor). The input has a isReadyForMoreMediaData property you need to check before you can write another frame. I’m recording in real-time (or as close to as possible).
Right now, when ARKit.ARSession gives me a new session I immediately pass it to the AVAssetWriterInput. What I want to do is add it to a queue, and have loop check to see if there’s samples available to write. For the life of me I can’t figure out how to do that efficiently.
I want to just run a while loop like this, but it seems like it would be a bad idea:
func startSession() {
// …
while isRunning {
guard !pixelBuffers.isEmpty && writerInput.isReadyForMoreMediaData else {
continue
}
// process sample
}
}
Can I run this a separate thread from the ARSession.delegateQueue? I don't want to run into issues with CVPixelBuffers from the camera being retained for too long.
I'm making an iOS app which lets you remotely control music in an app playing on your desktop.
One of the hardest problems is being able to update the position of the "tracker" (which shows the time position and duration of the currently playing song) correctly. There are several sources of input here:
At launch, the remote sends a network request to get the initial position and duration of the currently playing song.
When the user adjusts the position of the tracker using the remote, it sends a network request to the music app to change the position of the song.
If the user uses the app on the desktop to change the position of the tracker, the app sends a network request to the remote with the new position of the tracker.
If the song is currently playing, the position of the tracker is updated every 0.5 seconds or so.
At the moment, the tracker is a UISlider which is backed by a "Player" model. Whenever the user changes the position on the slider, it updates the model and sends a network request, like so:
In NowPlayingViewController.m
[[slider rac_signalForControlEvents:UIControlEventTouchUpInside] subscribeNext:^(UISlider *x) {
[playerModel seekToPosition:x.value];
}];
[RACObserve(playerModel, position) subscribeNext:^(id x) {
slider.value = player.position;
}];
In PlayerModel.m:
#property (nonatomic) NSTimeInterval position;
- (void)seekToPosition:(NSTimeInterval)position
{
self.position = position;
[self.client newRequestWithMethod:#"seekTo" params:#[positionArg] callback:NULL];
}
- (void)receivedPlayerUpdate:(NSDictionary *)json
{
self.position = [json objectForKey:#"position"]
}
The problem is when a user "fiddles" with the slider, and queues up a number of network requests which all come back at different times. The user could be have moved the slider again when a response is received, moving the slider back to a previous value.
My question: How do I use ReactiveCocoa correctly in this example, ensuring that updates from the network are dealt with, but only if the user hasn't moved the slider since?
In your GitHub thread about this you say that you want to consider the remote's updates as canonical. That's good, because (as Josh Abernathy suggested there), RAC or not, you need to pick one of the two sources to take priority (or you need timestamps, but then you need a reference clock...).
Given your code and disregarding RAC, the solution is just setting a flag in seekToPosition: and unsetting it using a timer. Check the flag in recievedPlayerUpdate:, ignoring the update if it's set.
By the way, you should use the RAC() macro to bind your slider's value, rather than the subscribeNext: that you've got:
RAC(slider, value) = RACObserve(playerModel, position);
You can definitely construct a signal chain to do what you want, though. You've got four signals you need to combine.
For the last item, the periodic update, you can use interval:onScheduler::
[[RACSignal interval:kPositionFetchSeconds
onScheduler:[RACScheduler scheduler]] map:^(id _){
return /* Request position over network */;
}];
The map: just ignores the date that the interval:... signal produces, and fetches the position. Since your requests and messages from the desktop have equal priority, merge: those together:
[RACSignal merge:#[desktopPositionSignal, timedRequestSignal]];
You decided that you don't want either of those signals going through if the user has touched the slider, though. This can be accomplished in one of two ways. Using the flag I suggested, you could filter: that merged signal:
[mergedSignal filter:^BOOL (id _){ return userFiddlingWithSlider; }];
Better than that -- avoiding extra state -- would be to build an operation out of a combination of throttle: and sample: that passes a value from a signal at a certain interval after another signal has not sent anything:
[mergedSignal sample:
[sliderSignal throttle:kUserFiddlingWithSliderInterval]];
(And you might, of course, want to throttle/sample the interval:onScheduler: signal in the same way -- before the merge -- in order to avoid unncessary network requests.)
You can put this all together in PlayerModel, binding it to position. You'll just need to give the PlayerModel the slider's rac_signalForControlEvents:, and then merge in the slider value. Since you're using the same signal multiple places in one chain, I believe that you want to "multicast" it.
Finally, use startWith: to get your first item above, the inital position from the desktop app, into the stream.
RAC(self, position) =
[[RACSignal merge:#[sampledSignal,
[sliderSignal map:^id(UISlider * slider){
return [slider value];
}]]
] startWith:/* Request position over network */];
The decision to break each signal out into its own variable or string them all together Lisp-style I'll leave to you.
Incidentally, I've found it helpful to actually draw out the signal chains when working on problems like this. I made a quick diagram for your scenario. It helps with thinking of the signals as entities in their own right, as opposed to worrying about the values that they carry.
I'm making a game where i have a character moving through a maze collecting coins. Once I have collected 10 coins i want my game to automatically go to the end keyframe. The variable Coincounter keeps a record of the number of coins the user has collected so far. So far i have this code to make my game do that....
if (_root.Coincounter == 10) {
trace("got to ten" +_root.Coincounter);
gotoAndStop(4) ;
}
The code is inside an onClipEvent - either keyDown or enterFrame, i can put it in either of them. The trace works fine so it's my gotoAndStop code that doesn't work - i'm not sure why. Thanks for the help.
How do I drive an animation loop or game loop at 60fps in a Dart web application?
Use window.animationFrame, the Future-based cousin of the traditional window.requestAnimationFrame.
Dart has been shifting to use Future and Stream as more object-oriented ways to handle asynchronous operations. The callback-based (old 'n busted) requestAnimationFrame is replaced by the Future-based (new hotness) animationFrame.
Here is a sample:
import 'dart:html';
gameLoop(num delta) {
// do stuff
window.animationFrame.then(gameLoop);
}
void main() {
window.animationFrame.then(gameLoop);
}
The signature of animationFrame looks like:
Future<num> animationFrame();
Notice how animationFrame returns a Future that completes with a num, which holds a "high performance timer" similar to window.performance.now(). The num is a monotonically increasing delta between now and when the page started. It has microsecond resolution.
The Future completes right before the browser is about the draw the page. Update the state of your world and draw everything when this Future completes.
You must request a new Future from animationFrame on every frame, if you want the animation or loop to continue. In this example, gameLoop() registers to be notified on the next animation frame.
BTW there is a pub package named game_loop, which you might find useful.
Okay, here's the rub. I'm making a little maze game. In this maze game, I have walls. They link to a class called Wall.as. In order to collision detect with the player, I do this:
MovieClip(parent).checkCollisonWithPlayer(this);
Where (parent) is a manager logic class. The parent does this
public function checkCollisonWithPlayer(wall:MovieClip)
{
if(player != null)
{
Collision.block(player,wall);
}
}
Now here's my problem. I have a class of Bullet.as that does much the same thing:
private function onEnterFrame(event:Event):void
{
x+= _vx;
//Check for collisions with walls and enemies
MovieClip(parent).checkCollisionWithEnemies(this);
//Remove if it leads off the stage
if (x > stage.stageWidth)
{
parent.removeChild(this);
}
}
What if I wanted to check for a collision between one of these bullets() and one of these walls()? How can I do that? They're never in the same function at the same time and there's almost certainly more than one of each in play at any time. I'm new to AS and this feels like a common issue, but I couldn;t dig up any material that made sense.
Here;s what I need:
public function checkCollisonWithWall(wall:MovieClip,bullet:MovieClip)
{
if(bullet.hitTestObject(wall))
Collision.block(bullet,wall);
}
}
But of course that doesn't work. What are my options?
On a simple level:
1) separate out physics from everything else: it makes things easier and more reusable.
2) have each physics object register itself with, say, a physics manager. things that you need to keep track of are if the object is static or dynamic (moving) and maybe even a shape flag (if you only wanted to collide certain objects with other objects). a shape flag is simply an int that tells you what type it is
3) have one onEnterFrame event, not an enter frame for each object. this will make your life easier
4) on this single onEnterFrame event, call on your physics manager to update the objects and see if any are colliding. You can to check collisions between static and dynamic objects, and (possibly) dynamic objects against other dynamic objects. You can use shape flags to cull out unnecessary tests. If you find a collision, you can dispatch an event/notify your objects/remove them from the game whatever.
something like
private function _init():void
{
// create 4 walls
for( var i:int = 0; i < 4, i++ )
{
var w:Wall = new Wall;
// position and add to stage etc
// add it to the physics manager (they don't need an update)
this._physicsManager.addStatic( w, ShapeFlags.WALL );
}
// create 10 bullets
for( i = 0; i < 10; i++ )
{
var b:Bullet = new Bullet;
// position and add to stage etc
// add it to the update and physics manager
this._updateManager.add( b );
this._physicsManager.addDynamic( b, ShapeFlags.BULLET ); // ShapeFlags is a static class of different types of objects
}
}
private function _onEnterFrame( e:Event ):void
{
// if you're moving your objects based on time, then
// dt is "delta time", i.e., the amount of time that
// has passed since the last update
// you can have an update manager that will move your
// different objects according to their speed.
this._updateManager.update( dt );
// now your objects have moved to their new position,
// get the physics manager (though in fairness, if it's
// only doing collisions, then it should just be a
// collisions manager) to check for collisions
this._physicsManager.update();
// do whatever else
}
This is a very simple example. Here, we're moving objects, then checking for collisions. You could possible run into problems with objects that are moving too fast and passing through each other, so no collision is registered. Something like this:
// frame one: object a is heading towards object b
// and object b is heading towards object a
(a)-> <-(b)
// frame two: because of their speed, they pass through
// each other, and you don't see a collision
<-(b) (a)->
This system is the easiest and simplest way to do this and is probably fine for a lot of games. If you want more complicated (as in checking for collisions between frames), then it's a bit more complicated, but you can still build on this.
Collision detection/response is a big topic, and you can find hundreds of code examples around the net. A good code structure can make the world of difference however.
It looks like the parent manager class has permanent references to the player and the enemies that it uses for collision detection. So also give it references to the walls and bullets.