Replace string in string

Hello, in my computercraft 'internet' I use 'packets' and I need to how drop the first sections of then. An example would be

update-router-137

This would update with the router software to computer ID 137, It then send a 'packet' back as follows:

updatereply-router-CODE

I then need to replace "update-reply-router-" with blank so only CODE saves into a file

I have 3 variables as follows

V1
V2
V3

and in the program it seperates them like this from the example 'packet' above

V1 = updatereply
V2 = router
V3 = CODE –this is only the first line of code, so it is basically useless, if I could get the whole code then my problem would be solved :)/>

I tried this:

s = command -- the whole 'packet'
s = s:gsub(V1.."-".."V2.."-"."")

This basically didn't do anything and I tried this too:

s = command -- the whole 'packet'
s = s:gsub(V1,"")
s = s:gsub("-","")
s = s:gsub(V2,"")
s = s:gsub("-","")

this replaces it but leaves y-r-

So my question is why dosen't V3 display the whole code, but instead it just displays the first line?

local function Parser()
line = {}
for word in string.gmatch(command, "[^-]+") do
table.insert(line, word)
end
V1 = line[1]
V2 = line[2]
V3 = line[3]
Case()
end

If you want to take a table and send it, you'd be better off literally just sending the table as-is. For eg:

line = {updatereply, router, CODE}
rednet.send(target, line)

If you're on one of the older builds of ComputerCraft, where tables can't be sent, then look into textutils.serialize() / textutils.unserialize().

Bomb Bloke, on 08 October 2014 - 01:10 AM said:

If you want to take a table and send it, you'd be better off literally just sending the table as-is. For eg:

line = {updatereply, router, CODE}
rednet.send(target, line)

If you're on one of the older builds of ComputerCraft, where tables can't be sent, then look into textutils.serialize() / textutils.unserialize().

But in the router code I need each section seperated so it knows where to forward the information too or where to send it, but when I print the V3 variable only the first line is there, not the rest.

What are you sending it, and what does V3 give out?

Dragon53535, on 08 October 2014 - 05:14 AM said:

What are you sending it, and what does V3 give out?

What is actually being sent is:
updatereply-router-local modemSide = "top"
local MPSID = "113"
local command = ""

etc….

What V3 outputs is:
local modemSide = "top"

Why not just use a table? You can easily set it up so that you find out what is being sent.

local tbl = {type = "Command1",Returnto = 5, MPSID = "113", ["update-reply-local modemSide"] = "top"}

for key,value in pairs(tbl) do
  if key == "type" then
    --#Oh the table's used for this purpose.
  elseif key == "Returnto" then
    rednet.send(value,"Hi") --Send message Hi to the Returnto address
  elseif key == "MPSID" then
    --#Do whatever with MPSID :P/>
  end
end

Dragon53535, on 08 October 2014 - 06:33 AM said:

Why not just use a table? You can easily set it up so that you find out what is being sent.

local tbl = {type = "Command1",Returnto = 5, MPSID = "113", ["update-reply-local modemSide"] = "top"}

for key,value in pairs(tbl) do
  if key == "type" then
	--#Oh the table's used for this purpose.
  elseif key == "Returnto" then
	rednet.send(value,"Hi") --Send message Hi to the Returnto address
  elseif key == "MPSID" then
	--#Do whatever with MPSID :P/>/>/>
  end
end

I think you are a miracle working, this makes the packet system so much easier, but can this handle large amounts of data Yes it can, thank you!!!

yeah, tables and rednet have no size limitations.

I do suggest you look into using the modem api directly though, as opposed to using the Rednet API, especially since you're wanting to do routing and such. the modem API allows for channels.

theoriginalbit, on 08 October 2014 - 06:55 AM said:

yeah, tables and rednet have no size limitations.

I do suggest you look into using the modem api directly though, as opposed to using the Rednet API, especially since you're wanting to do routing and such. the modem API allows for channels.

I tried wired modems before and they have a length limit and my city is huge and I can just increase the wireless modem range in the config

theoriginalbit, on 08 October 2014 - 06:55 AM said:

I do suggest you look into using the modem api directly though, as opposed to using the Rednet API, especially since you're wanting to do routing and such. the modem API allows for channels.

Huh. That is exactly the opposite of what I would recommend for someone wanting to do routing. In the simplest case, the repeat program would be all one would need, and for more complex cases, the rednet API provides useful facilities that can be taken advantage of (consistent packet structure, packet ID numbers, use of a table allowing extra data to ride along seamlessly), and if the programmer wanted to go yet deeper, the rednet API provides an API interface that can be relatively easily overridden to provide whatever advanced functionality they choose to add.

I absolutely suggest the use of the rednet API for any communications that are done as point-to-point between two specific computers. It's a useful abstraction that allows transparent extension of the functionality of your code. I would suggest the modem API for use cases where you want to deal with multiple computers at once (like GPS!) or otherwise have need of functionality that the rednet API cannot provide.

I'm definitely curious to hear why you'd recommend the modem API instead. :)/>

If all you want to do is get messages from A to B, sure, use rednet. The code's pretty much the same either way, but these days you get repeat and host lookup features if you do.

But if you want to set up your own "routing system"… well, as it stands, the only thing that could be remotely compared to "routing" in vanilla ComputerCraft is the "repeat" script you mentioned, which uses the modem API to operate. Likewise, if you want to override any of the base rednet behaviours, you'll be using the modem API to do it.

In any case, one's understanding of rednet (and the way ComputerCraft handles networking) will be greatly improved by reading up on how to interface with modems directly. I'd furthermore recommend reading through the source of the rednet API (as available in rom/apis).

To further extend upon what Bomb Bloke said, being able to use channels could be very beneficial for networking, specifically routing, because it could allow you use different channels for different tasks, to help further abstract the process away from the programs trying to use the routing protocol.

For example, you could use a particular channel to perform the distribution of the node tables that aid in path resolution, or you could use a different channel to perform pings to check for nodes, etc, while still having main communication happen over another channel. Sure it could also be done with some packet type IDs and some if statements, but why not just use channels for things like this.

Perhaps it could be used to have multiple transmission layers, perhaps some secure ones and insecure ones, I don't have exact use cases on where I think it should be used, but it is definitely knowledge that one should have, to know how things work.

theoriginalbit, on 08 October 2014 - 09:59 AM said:

To further extend upon what Bomb Bloke said, being able to use channels could be very beneficial for networking, specifically routing, because it could allow you use different channels for different tasks, to help further abstract the process away from the programs trying to use the routing protocol.

For example, you could use a particular channel to perform the distribution of the node tables that aid in path resolution, or you could use a different channel to perform pings to check for nodes, etc, while still having main communication happen over another channel. Sure it could also be done with some packet type IDs and some if statements, but why not just use channels for things like this.

Perhaps it could be used to have multiple transmission layers, perhaps some secure ones and insecure ones, I don't have exact use cases on where I think it should be used, but it is definitely knowledge that one should have, to know how things work.

Bomb Bloke, on 08 October 2014 - 09:22 AM said:

If all you want to do is get messages from A to B, sure, use rednet. The code's pretty much the same either way, but these days you get repeat and host lookup features if you do.

But if you want to set up your own "routing system"… well, as it stands, the only thing that could be remotely compared to "routing" in vanilla ComputerCraft is the "repeat" script you mentioned, which uses the modem API to operate. Likewise, if you want to override any of the base rednet behaviours, you'll be using the modem API to do it.

In any case, one's understanding of rednet (and the way ComputerCraft handles networking) will be greatly improved by reading up on how to interface with modems directly. I'd furthermore recommend reading through the source of the rednet API (as available in rom/apis).

I get what you all are trying to say and yes, I agree the channels would defiantly help and in my past experience, computercraft's networking cables have a length limit (not size (data) but the length of the cable) and after X amount of blocks it just doesn't work anymore, unless they changed this, it would be virtually impossible to have such a system like mine and use the cables due to their limited length, I just use wireless modems and do multiple validity checks to make sure the information is coming from the router only [or the intranet] and not the internet.

The range of the network cables are 256 blocks

theoriginalbit, on 08 October 2014 - 12:40 PM said:

The range of the network cables are 256 blocks

In the situation I have, I have the city and then I have the suburbs which the distance is over 500 blocks, but I was thinking of making 'switches' and those will just forward all information on side 1 to side 2 and vise-versa

Bomb Bloke, theoriginalbit;

You both make good points. For whatever reason, I thought when theoriginalbit recommended the use of the modem API, it was for client programs to be used with the system, which is the idea I was objecting to. Of course, a routing system will itself almost certainly need to use the modems more directly, though whether or not other frequencies would be necessary depends on the design of the API. For instance, LyqydNet does use the modem API directly, but all of the traffic between nodes uses the rednet-style scheme of sending on the frequency of the intended recipient's computer ID, and putting its own ID as the reply channel, with the one exception of rednet-style broadcasting using the rednet broadcasting channel. It also overrides the rednet API to provide additional functionality (routing) for all programs using the rednet API.

@jubba890, I might be misunderstanding but, based on your replies, I'm getting the impression that you believe the modem api only works with wired modems. Just to clarify, both the modem and rednet APIs work with wired and wireless modems - they don't limit you to one or the other. My apologies if I misunderstood.

Dog, on 08 October 2014 - 10:43 PM said:

@jubba890, I might be misunderstanding but, based on your replies, I'm getting the impression that you believe the modem api only works with wired modems. Just to clarify, both the modem and rednet APIs work with wired and wireless modems - they don't limit you to one or the other. My apologies if I misunderstood.

They do limit you if you do the wired modems because of a limit that you can only build 256 network cables before the signal completely drops

Just so long as you understand that the 256 cable limit for wired modems has nothing to do with the modem API.

No one here has suggested you use a wired modem. Use of the modem API is the same regardless as to whether you are using a wired or wireless model.

Bomb Bloke, on 09 October 2014 - 02:52 AM said:

Just so long as you understand that the 256 cable limit for wired modems has nothing to do with the modem API.

No one here has suggested you use a wired modem. Use of the modem API is the same regardless as to whether you are using a wired or wireless model.

I do understand that, and as above they were saying the channels on the wired modems would be helpful for routing and I said the wired modems would not work because of their range limit.

You are misunderstanding what they said. What they were saying above is that the channels feature available via the modem API would be useful.

Both wireless modems and wired modems are modems, and both work with the modem API. Nobody said you had use to wired modems to make use of the channels feature; and that's what I was trying to point out before. My apologies if I wasn't clear.

Dog, on 09 October 2014 - 04:43 AM said:

You are misunderstanding what they said. What they were saying above is that the channels feature available via the modem API would be useful.

Both wireless modems and wired modems are modems, and both work with the modem API. Nobody said you had use to wired modems to make use of the channels feature; and that's what I was trying to point out before. My apologies if I wasn't clear.

I thought rednet was with wireless and the modemAPI was for wired? I tried rednet with wired so I figured it did not work vise-versa

Nope, you can use both the modem API and the rednet API on both the wired modems and the wireless modems. The modem API even includes an isWireless call, which is the only way to know which you're using!

for modems rednet is really a kind of wrapper for the modem api. Rednet uses the modem api and changes it a bit to work with computer ID's as the channels, which is why rednet isn't secure as you can just listen in on the channel with the modem api.

Edit: Didn't realize wired could use rednet, seems you learn something new. However the statement still stands.

Dragon53535, on 11 October 2014 - 05:33 AM said:

for modems rednet is really a kind of wrapper for the modem api. Rednet uses the modem api and changes it a bit to work with computer ID's as the channels, which is why rednet isn't secure as you can just listen in on the channel with the modem api.

Edit: Didn't realize wired could use rednet, seems you learn something new. However the statement still stands.

I tried using rednet with wired and for me it didn't even work, it opened the modem but would not transmit/receive information

Did you use rednet.receive()? and did you use rednet.send()? Because i have most certainly done so on a CC 1.57 server

Dragon53535, on 11 October 2014 - 09:41 PM said:

Did you use rednet.receive()? and did you use rednet.send()? Because i have most certainly done so on a CC 1.57 server

Yes I did, the only thing that worked was the rednet.open()

Go through and make sure you completed the cabling run. If your cabling length is long, just for testing purposes, try plonking two computers right next to each other and see if you can make it work at short range. Post the code if you're still stuck.