(0245) Context Class Name: #BLOCK_167_DESCRIPTION
The Cloaker is capable of rendering anobject completely invisible
The Cloaker is capable of rendering an object completely invisible

Another typo in the description of all metal capsules, the example uses Hylat:

(0016) Context Class Name: #BLOCK_108_BLOCKNAME
Funal Trap
Fungal Trap

(0211) Context Class Name: #BLOCK_212_DESCRIPTION
-Structural Stats- $ARMOUR%Armour $HP HP
-Structural Stats- $ARMOUR% Armour $HP HP

It's only a visual issue so keeping it on low priority.

-QA Testing-
Fix confirmed. Behaviour and displayed info match the config.

No longer able to reproduce on MP or SP. Must've been a temporary issue caused by server lag. (though that doesn't explain why I've seen the issue before...)

confirmed while validated
checked lower case alphabet and only jj seems to produce this

-validated-

Okay - closing then.

Last Chance for reply before i close this...
-Rejected-

I suppose it can be, i haven't had any responses. Your call. just let me know.

Oh, didnt try that small, lol, yeah.. hm will try it again.

So this can be closed?

Its not a full duplicate, but as there are several problems in loading/unloading them, and even clearing the client cache can cause the behaviour in the mentioned issue can trigger, I'll merge it there and we have to look into the details again, after the other issue is fixed.

After using other blocks to get it to bring the cursor up. When placed more blocks on it. It says, "area not initialized yet please place blocks slower"

i also have noticed the ability to create groups in only certain sections of the XML have been removed in recent releases:

in addition to the placement issues noted above, i am noticing that regardless of the ship i am in, only an "/initiate_wave 1 1 -1" equivalent group of reinforcements is ever spawned in.

Ok .. missunderstanding in wording then.
I was in fact talking about power storage in excess of the 50K provided by the core due to additionally placed power storage blocks.
Sorry for wording that wrong.

-Confirmed- in Dev.
Create a core and build up. pay attention to the height dimension. I built using 10 at a time and thirty. If i remove the blocks the difference is left, with nothing to remove.

I'm was saying there is 50K storage their because you said there was none. "Your turrets do not have power storage on there own as far as i can see."

Here's an example:

GRHayes ... again take a look at T539 ... i am well aware of this core without power gen having 0e/s and placing and removing a power gen changing that to 1e/s as long as the entity is loaded. that effect is already fixed in Dev Build.

-Confirmed-

http://starmadedock.net/threads/block-count-is-off.21446/
You can find the ship here. And image proving the count is off before saving. Second ship worse. off 12%.

First, off you are dead wrong on the turrets not having 50K storage. Anything with a core has 50K. You can verify it the way I just did. Put a single power supply on the turret and what it charge 50K. Take it off it doesn't go down 50K. Now fire the turret and it will show it being 50K less.
Coincidentally you end up with same out of power again which still get while firing.

Please Upload the Ship...

happens as being described

-Validated-

Similar to @Phocian, I was standing inside of a tower attached to my homeworld. A turret from below the tower fired a missile salvo at a pirate ship when the tower was in its line-of-sight. I was killed inside the tower. So I assume the blast radius of the missiles penetrated the tower even though it's invulnerable (and has shields). Is this the desired effect? I know it's a friendly fire incident, but it shouldn't be happening through a structure that's invulnerable and/or shielded.

If people are using wireless (expensive in game overhead) to get rid of logic pipes wouldn't the concept of eliminating the pipes except in build mode do the job best?

-Validated-

FYI reinstalled JDK 7 and JRE 7 confirming 64-bit on both.
Result: Issue still occurs

-Confirmed-

Similar problems are around where menus show inconsistent data ( like T669)
Keeping this open and maybe test all the defensive effects for shown info.

-Duplicate-

I couldn't get it in SP, but could in MP. It seemed like the NPC was pulled with Gravity before the station was rendered and fell thru. But that wouldn't explain the continual loop

A log from one of those events by Jananton