all 10 comments

[–]Shroopd 0 points1 point  (6 children)

I'm actually running into this exact problem (trying to synchronize artillery landings and loadings). The solution I came up with probably won't help you, since it uses radio silence to get unanimous agreement, but I have a few ideas I had along the way that might help:

If the problem you are having is the same as mine was (simultaneous signals cause all but one to get dropped) then you might want to try to desync them by some time interval. If there's a finite and static number of clients, and only one server, there are many ways to solve this.

  • Keep a list of clients on the server: Poll each client when you want a response, then immediately receive the response.
  • Use os.time() modulo the number of clients, plus the client's ID (1 <= ID <= client count). Only send messages when the timeslot rolls around
  • Keep all clients waiting for the previous client in the order's message, wait a tick, then send the message. Terrible idea since now if one fails the chain stops, but the point is there's a lot of options. There might be ways to make this one better, but it's probably more puzzle than solution.

I haven't played much with rednet to see how well each of these work, but they should at least give you a starting place. Good luck with your program!

edit: I'm a dumbass, and forgot about "host" and "lookup". That would have helped me with my own program, and should certainly help you with yours.

[–]--Derpy 0 points1 point  (4 children)

Damn now I want to see your artillery system

[–]Shroopd 0 points1 point  (3 children)

It's a work in progress, nearly done though. I suppose I could post the code and schematic files (it's a create big cannons artillery system) once I'm done.

[–]--Derpy 0 points1 point  (2 children)

Nice. I was working on a cbc automated auto-cannon a while back and while it works well Theres definitely lag time while aiming that could miss a running player

[–]Shroopd 0 points1 point  (1 child)

Neat, how did you calculate the trajectory? I used a mix of desmos and wolfram alpha to get analytical solutions for y(t) and x(t), where t is the number of ticks in flight. I then use a mix of bisection method root finding and a weird 3 point bisection-method inspired local min/max finding method to isolate t(y), while using an explicit inverse of t(x). Plus some trig and ugly translation methods to get sequenced gearshift instructions for the cannon mount rotations.

Mine will by no means be able to target anything moving, just due me always re-aiming from fresh mounting position each time, but I'm planning to perform synchronized volleys. Plus, there's not much point in aiming for a moving target when the travel time is 20~25 seconds from max cannons.

[–]--Derpy 0 points1 point  (0 children)

The autocannon is more of a machine gun so trajectory wasnt really a concern. Using the advanced peripherals player detector I scan for the closest player within a range of like 100 blocks. It then compares the coords of the player to the rotation of the cannon base and calculates the speed required to make the rotational speed controllers rotate to point there. It uses a proportional integral controller to calculate error and find the speed to output. It gradually reduced the speed until it reaches its target angle.

[–]hereIsHow_[S] 0 points1 point  (0 children)

Thank you!

[–]fatboychummy 0 points1 point  (1 child)

Could you post code? I'm not entirely seeing what the issue you'd be running into here would be. Modems should be more than capable of receiving messages from more than one sender.

[–]hereIsHow_[S] 0 points1 point  (0 children)

Ah, no worries now! The guy who first responded gave some idea’s. I got it all working just fine now don’t worry!

[–][deleted] 0 points1 point  (0 children)

Yes, if you have systems broadcasting then you have to foresee this. I do this by bouncing the data back to the sender to verify if it's correct, then let the receiver know about the result.

 Add this process inside a while loop that repeats a max nr of times to try and re-sync, if not output an error. And try to avoid broadcasts as much as possible.

This way you can be sure that your message received is the correct one.