power

/proc/propagate_network(var/obj/O, var/datum/powernet/PN)
	var/list/P = list()
	if( istype(O,/obj/structure/cable) )
		var/obj/structure/cable/C = O
		if(C.powernet==PN)return
		C.powernet.cables-=C
		C.powernet = PN
		PN.cables+=C
		P = C.get_connections()

	else if(O.anchored && istype(O,/obj/machinery/power))
		var/obj/machinery/power/M = O
		if(M.powernet==PN)return
		M.powernet.nodes-=C
		M.powernet = PN
		PN.nodes+=C
		P = M.get_connections()

	else
		return

	for(var/L in P)
		propagate_network(L, PN)

/datum/powernet/proc/denode(var/obj/structure/cable/C)
	var/turf/T1 = C.loc
	if(!T1)	return
	var/list/powerlist = power_list(T1,C,0,0)
	var/datum/powernet/PN = new()
	propogate_network(powerlist[1],PN)

Hello, I want to get some feedback about something I'm working on.
I discovered that there are some discrepancies in the code for cables and powernets . Essentially the problem boils down to this: There is a makepowernets procedure which admins can run which rebuilds the powernets, for performance reasons this isn't run every time a cable is changed. Instead the changes are made incrementally to the effected powernets when you change a cable. However these two processes provide different results causing confusion and bugs.

The makepowernets procedure builds the networks correctly and in the way described on the wiki here: [url]http://wiki.nanotrasen.com/index.php/Basic_construction#Wiring[/url]. The important thing to note is that two cables running "smoothly" perpendicular across the same tile do not connect. "Dotted" or "knotted" cables or "Nodes" on those two cables will cause them to connect. This is good, it allows the most functionality, multiple cables can connect or not connect on the same tile according to the users wishes. Unfortunately the incremental logic used when a cable is placed does not use this logic*, so that any cables will connect regardless of whether they have this "Node". This means two cables can never cross and not connect without running makepowernets again. This by itself is irritating but as I was digging into this I found that it causes more problems. The process for dealing with cutting cables uses the first set of rules so it can fail to detect that two cables are connected according to the rules of placing cables and not disconnect the two powernets. This means disconnected pieces of wire can according to the powernet system be connected and share power.

The solution is to pick one set of rules and stick with it.
This is my proposed solution
1. When adding a cable to a tile only connect to other cables on the tile if they are connected or dotted
2. After adding a cable to a dotted cable causing it to become smooth do the following
	a. find another dotted cable on that tile(if there is none happy days)
	b. propagate a new powernet along the first cable we find, this will also propogate to any other cables dotted on that tile.
	c. If there was a loop this will actually completely replace the old powernet so remove it if it has no cables left
Worst case this process requires traversing the entire graph once unnecessarily(In the case of a loop), which is better than the current code for cutting a cable which is an inefficient mess.

* I believe originally makepowernets was called everytime you placed a cable, this is ridiculous and some simple logic was added to replace this which did not take into account the complexity of dotted cable