Discussion in 'Programming (In-game)' started by rexxar, Jan 19, 2017.
Is there a way for the PB to know which local-grid antenna caused it to run?
Short answer is NO.
Long answer is that you don't need to worry about this if you use radio antennas since they get messages from everyone and hop them around to any other radio antenna in range. (And so you probably will have 1 radio antenna on a grid.)
For laser antennas what I do is including the receiving antenna blockID as part of the message so the PB extract that from the message and compare to the laser antennas on the grid.
This is only needed of course if you plan to have more then one laser antenna on the same grid.
Problem with this is how to make sort of handshake message so two grid will know they talk with each other and not with other grids.
Finally. Good Job.
I'm almost convinced to come back to SE. But not quite, i still need a radar block or functionality so i realistically can use my radar script for longer ranges than 100 m.
Until then i'm at 50% reputation in my Kerbal Spaceprogram.
On that note, will we see real orbital mechanics in SE?
There is Lidar in SE.
Please note that LIDAR is not enough, and we still need more powerful and easy-to-access-without-programming sensor blocks for detecting other objects at long range, and by symmetry, warning when active sensors are being used against you. Extensive discussion <here>.
OK. /Goes back to test firing missiles at 47km targets using lidar.
/ Goes back to scanning beyond 1000 km and slagging the server-side-simspeed occasionally.
Hmmm. so now all we need is some basic saltable hash process to generate a verifiable signature for messages so people can't just spam broadcast to all in range with copy cat messages.
I feel like a set of IR transmitter/reciever blocks could be very useful now.
Edit for clarification:
Basically, an antenna that raycasts out in a cone a short distance. It transmits to any valid recievers detected within the cone. The usage would be that you can choose to only broadcast to specific grids without the need to change commands or to transmit identifiers, making such code redundant in a script. Now you can transmit to a desired grid without needing to lock, and without the wrong grids picking up the message, and without extra code to limit the transmission.
Don't we have those?
They are called Laser antennas
You could always have the ship identify itself by grid number in the message and then have the responding station check its sensors for the location of that ship and open the nearest hanger.
Well... why not just have the ship broadcast it's position and orientation?
If you only transmit the message to your own antennas then only your own ships will get the message anyway >.>
And the first method I proposed wouldn't require you to send your location at all....
But sure, if you really want something that is really situational the best bet is to mod it in yourself.
Save that you can always hope someone else mods it in or go for the real long shot that Keen does it later.
I wont propose any more immediatly implamentable solutions to your posed problems so you can carry on pining after something you will likely have to create yourself if you ever want to see it realised >.>
Sorry for trying to offer practical solutions...
You know things that can be done now rather that wait for something else that may never happen.
But hey. not for me to tell you how to do things, If you want to wait around rather than get a working solution now that is up to you
I never requested a solution. All I did was state that such a block could possibly be useful. Don't offer unsolicited advice and then become irate when it's ignored. Also, I never said that I would be relying on anyone else to create such a block. I don't know why you came to that conclusion, but it was incorrect.
Edit for anyone confused: I've deleted previous comments save for my original one, as the others served no purpose to the thread.
You know... what i think we have here is a failure to convey tone...
Now I tried to be helpful, you accused me of having an attitude now of being irate...
as far as I can see you have no grasp of the fact I was trying to be helpful so how about you take a step back and cool off for a while.
If you don't want my advice, fine, but there is no need to go attacking me over it.
Your obstinate pressuring of unsolicited advice as well as claiming that I was "pining" and try to offload work on others was anything but friendly.
I have no idea what pinning refers to in this context
and are you accusing me of trying to offload work onto others or saying I was accusing you of it...
Because I did sugest your best bet was to make it yourself if you wanted it. I went on to say that waiting for others to do so was less likely and waiting on keen to do it would likely result in it never happening, so how are you interpreting this as me saying you are trying to offload work onto others?
This is a public forum.... If you don't want people to respond to you, don't post on a public forum.
I wrote "pining," not "pinning." And comments like "You know things that can be done now rather that wait for something else that may never happen" indicates that I might expect someone else to do it, which was a useless and baseless assumption, whether it's a rational one or not. I never made any indication that I intended to make it nor expected anyone else to do so. Again, I only stated that it could be a useful block. Yes, this is a public forum, and I should expect responses. Receiving the response was not the issue I had. You offered several solutions that I was already aware of being possible, which is also fine. When I attempted to clarify why I saw my concept as being more useful in certain situations, you acted as though I requested your solutions and then arrogantly ignored them. That was the issue. Your solutions would certainly be an alternative, but I wasn't looking for one. If you offered the solution once and left it at that, this unproductive path of discussion would have ended there. But you continued to offer more solutions to a problem that didn't exist. I take some responsibility for not bluntly saying "I know, but I'd rather do it this way." But when you turned and said I was "pining," as though I was being irrational, this indicated to me that you expect me to simply accept your satisfactory solution, rather than strive to create something to ease work in the long run. And in case you intend to ask how it would save work, it would be in the same way that recycling code in the form of functions does so. Rather than needing to add extra code into every programmable block for short-range, targeted communications, all a player would need to do is add the IR transmitter, add it to the PB like any other antenna, and be done. Point-and-shoot comms are ready to go without needing to add all of those extra lines of code on each end. This saves time when scripting for the PB, and makes things easier for newer scripters that would rather avoid implementing all of the extra calculations or data transmission/interpretation. Yes, that code would still be necessary for similar comms via current means. But if you only need local transmission, it saves a lot of work.
Can we get back on guide, please?
Well I set ignore on them, (a feature I didn't realise this forum had until now) and if they have any sence they did the same to me since apperently we are not compatible
So I wont be trying to either argue or help them any more.
I am quite tempted to set my signature to obstinately helpful though
Yes, thank you. My apologies. I should have stopped replying to this nonsense long ago.
I'm working on a protocol anyone intrested in helping?
What do you need?
For string parsing messages to carry identification and some sort of verification key?
I'm intresting in hearing your ideas if so ^.^
I'm already packing in keyword, grid ID, message and a basic and horribly flawed hash verification.
Right now the way I have been coming at it is to use keywords to identify the type of message.
So if a message is for example a status update, in most cases only the most recent needs to be processes, and having each message tagged witht he oragin ID means only one should be queued per source at any given time
By pairing a queue with a dictionary you can add the key of the dictionary pointing to the message to the queue. if a new status update ocmesin, you replace what is in the dictionary so it gets the place of the old message without needing to change the middle of the queue (which is tricky)
When the key comes up in the queue it is processes and if done successfully it is popped from the queue and deleted from the dictionary.
Other messages that all need to be processes can be handled in a similar way but you either have a dictionary of lists (not ideal since the list could have goodness knows how many messages and it could potencialy never end), or you just give every dictionary value a unique key and add that to the queue so they all get processed! which is what I prefered.
By limiting the length of the queues you can prevent serious overflow but as people have already pointed out this could be abused by flooding the antennas with spam. That was why I was looking for a verification hashing method that would secure against that sort of thing.
With the right kind of hashing (ideally low cost) you just need to verify the message based on the hash before putting it into the queue. Any that fail are disregarded as spam.
So as long as you don't give out your hashing salt you should be reasonably safe
I have been using queues to throttle how many messages get processed at once. I can't stop the PB being triggered every time a message is recieved, but it only fully processes the messages once every 0.75(ish) seconds.
I also added an output queue which is peeked from once every 0.75 seconds since that seems to be the most reliable time to avoid failure. If the transmission is successful it gets wiped from the queue.
Do tell me if I am overcomplicating this
Schema and taxonomy... schema and taxonomy.
It's a basic idea. I am working on it right now. <.<
pose goal, identify obstacles, pose solutions, implament solutions, goto 10 >.>
I begun working on it as part of my soon to be released OS script and before I used the Antenna Communication mod, but it was limited to 1k characters per message.
Now with vanilla support and no size limit per message it will be easier.
Currently for laser antenna but trying to fit for radio antenna too.
The first grid in the chain to broadcast a message will include the OriginalSenderID, which is the progblock ID number.
After some good testing I saw that for each grid and each block there is a unique ID number.
Then there is SenderID, which for the first grid is again the PB ID, but for every grid that forward the message, this number change to indicate who forwarded it.
For a grid to know a message was meant for it then two things are needed:
ReceiverRelayID need to match one of the antennas (if grid have more than one).
TargetID must match the grid PB ID that run the script.
This way you can also tell said grid to do things other than passing the message forward, like asking for status report or doing other operations.
There is also the SenderRelayID, the ID of the antenna that broadcasting the message.
Two grids talk with each other, each has only one laser antenna.
Each time one replay to the other, OriginalSenderID, SenderID and SenderRelay change in according to the broadcasting grid, while TargetID and ReceiverRelay change for the other grid.
It will look like this: [BOT][OriginalSenderID<oID>SenderID<sID>TargetID<rID>SenderRelay<SRelayID>ReceiverRelay<RRelayID>][MOT]
If there are three grids now and grid A want to talk with grid C, then grid A send the message as usual only TargetID will be of grid C, there for grid B will see the message is need to be forward and will do so.
For the sake to simplify this:
Grid A PB ID = 1, Grid B = 2 and C = 3
The message from grid B to C will have 1 as OriginalSender, 2 as the current Sender and 3 as the target, this will valid above conditions and based on the rest of the message grid C will know what to do.
[BOT] is Begin Of Transmission, [MOT] is Middle Of Transmission, [EOT] is End Of Transmission, and is used to break the string in half for better processing.
After [MOT] comes the part to decide what target grid should do.
Currently there are three options but will add more:
[MSG-Type<action> : Target will look in a list if action is valid and if pin code is correct before preforming an action.
[MSG-Type<data>Operation<GET/SET/ARRIVE> : With this you can set or get a value of a variable, if target grid get message with <GET> it will replay with <ARRIVE> and the value, or "null" or "not found" if variable not found.
You can monitor with this altitude of a satellite or tell it to go up or down for example.
<SET> message need to be followed by <action> type message before data is set.
Since I have code that turn the Storage into "file" storage then I probably gonna add something for transfering those files.
The third option is [MSG-Type<text>|some text to show|] : This will cause the text inside the || show on a screen.
I have three thigs that hold me from finishing this:
The low character count for scripts, 100k is not enough.
Handshake so automate the establishment of communication between two given grids
Adapting to radio antenna: since message already hop from antenna to antenna no need to broadcast it again from every
grid. This part might be easy to solve..
That's basically all for now..
I was rolling the idea around in my head of what a communication string should contain. There are some ideas coming across from standard protocols. But they may be too formal to be adopted or easily used.
Sender = who is broadcasting
Recipient = who should receive.
Action = Order or Comply or Query or Response
Data = to be constructed dependent on the action.
Orders are commands for the recipient to do something... move to a location, turn on/off weapons, etc.
Queries are asking for information
Response are answering the question
Separate names with a comma.