Hmm, well I guess when I take the keyboard's orientation into account it can work, yes. The problem is which screen does it "belong to" if there's a screen below it, too? But that may be a negligible corner case where it can just work for both screen... I'll add it to the list.
Well, currently you cannot place a keyboard on the front face of a screen. It simply wont let you.
What you could do is, instead of preventing this, when you try to attach it to the front of a screen, render the keyboard as shown below while still linking it with the screen that was clicked.
I'm talking about this in terms of keyboard placement:
It'd be nice to be able to make a little "office space" like this, but without using screens as a desk of course. : P
And this obviously doesn't work since the keyboard is linked to the downwards facing screens.
I also noticed that sometimes when placing screens facing up or down they will stop linking after a few seconds causing oddness like this:
Well, currently you cannot place a keyboard on the front face of a screen. It simply wont let you.
What you could do is, instead of preventing this, when you try to attach it to the front of a screen, render the keyboard as shown below while still linking it with the screen that was clicked.
They don't because in the current implementation that wouldn't make sense and just be confusing ("why isn't this keyboard working?"). That would obviously have to change, yes. Clicking on front of the screen to place it and make the association obvious is great idea, I guess that's how I'll do it.
1) the keyboard should have preferred sides (e.g., won't connect down unless there's no screen in front). It shouldn't be able to connect down or up though, as you can't see your screen if you're typing with the kb on top of it, and you can't use the kb if you have a screen on top of it (which would just be ridiculously silly )
2) maybe opening a GUI and not rendering anything? that way you can capture ALL kb input, and lock the player in place (the player won't be able to look around though, unless you override that mechanism in the GUI by making the angles change whenever the mouse moves).
I did not mean that the keyboard has to be placed like I suggested. It is merely a way to create a visually pleasing "office space" or similar with the screen and keyboard as I showed in the first screenshot while still being able to use them. But I'd still want you to be able to put the keyboard on the side or on top of the screen like you do right now.
I'd still want the gui to open like it does now when either the keyboard or screen is activated.
Here's a quick video I recorded which might better illustrate what happens:
Ah, that clears it up. They do have the wrong orientation (i.e. yaw, which controls how the text displayed on them is rotated). The screen's "up" direction (screen-space wise, i.e. where the top of the displayed text is) depends on the way you're facing when placing it, not its environment. So the screens you place at ~0:35 have an "up" direction 90 degrees counterclockwise of that of the other screens, and won't connect because of that.
I could ignore the yaw, but the issue with that is: which of the two orientations to use? That of the larger part, that of the most recently placed one? So I'd rather keep it like it is now.
Ah, that clears it up. They do have the wrong orientation (i.e. yaw, which controls how the text displayed on them is rotated). The screen's "up" direction (screen-space wise, i.e. where the top of the displayed text is) depends on the way you're facing when placing it, not its environment. So the screens you place at ~0:35 have an "up" direction 90 degrees counterclockwise of that of the other screens, and won't connect because of that.
I could ignore the yaw, but the issue with that is: which of the two orientations to use? That of the larger part, that of the most recently placed one? So I'd rather keep it like it is now.
Oh right, I see what happens. Maybe a subtle marker on the texture so you can tell which way "up" is would decrease confusion?
Oh right, I see what happens. Maybe a fairly subtle marker on the texture so you can tell which way "up" is would decrease confusion?
Something along those lines. I think I have a nice non-intrusive solution that won't require me re-writing anything: an overlay on screens indicating their yaw only shown when the player is holding a matching screen block. Will have to try it out to see how it looks.
I'm running Windows 7. Updated "VS2012 Visual C++ Runtime" to the newest version. Computer have power. and using it.
But I just notice I get this.
[22:55:58 INFO]: Client> java.lang.UnsatisfiedLinkError: C:\Users\Asbjoern\AppData\Local\Temp\native.64.dll: Can't find dependent libraries
[22:55:58 INFO]: Client> at java.lang.ClassLoader$NativeLibrary.load(Native Method)
[22:55:58 INFO]: Client> at java.lang.ClassLoader.loadLibrary1(Unknown Source)
[22:55:58 INFO]: Client> at java.lang.ClassLoader.loadLibrary0(Unknown Source)
[22:55:58 INFO]: Client> at java.lang.ClassLoader.loadLibrary(Unknown Source)
[22:55:58 INFO]: Client> at java.lang.Runtime.load0(Unknown Source)
[22:55:58 INFO]: Client> at java.lang.System.load(Unknown Source)
[22:55:58 INFO]: Client> at li.cil.oc.util.LuaStateFactory$$anonfun$1$$anon$1.load(LuaStateFactory.scala:129)
[22:55:58 INFO]: Client> at com.naef.jnlua.LuaState.<clinit>(LuaState.java:134)
[22:55:58 INFO]: Client> at li.cil.oc.util.LuaStateFactory$.createState(LuaStateFactory.scala:148)
[22:55:58 INFO]: Client> at li.cil.oc.server.component.Computer.init(Computer.scala:688)
[22:55:58 INFO]: Client> at li.cil.oc.server.component.Computer.start(Computer.scala:111)
[22:55:58 INFO]: Client> at li.cil.oc.server.PacketHandler.onComputerPower(PacketHandler.scala:31)
[22:55:58 INFO]: Client> at li.cil.oc.server.PacketHandler.dispatch(PacketHandler.scala:17)
[22:55:58 INFO]: Client> at li.cil.oc.common.PacketHandler.onPacketData(PacketHandler.scala:25)
[22:55:58 INFO]: Client> at cpw.mods.fml.common.network.NetworkRegistry.handlePacket(NetworkRegistry.java:255)
[22:55:58 INFO]: Client> at cpw.mods.fml.common.network.NetworkRegistry.handleCustomPacket(NetworkRegistry.java:245)
[22:55:58 INFO]: Client> at cpw.mods.fml.common.network.FMLNetworkHandler.handlePacket250Packet(FMLNetworkHandler.java:84)
[22:55:58 INFO]: Client> at net.minecraft.network.NetServerHandler.func_72501_a(NetServerHandler.java:1127)
[22:55:58 INFO]: Client> at net.minecraft.network.packet.Packet250CustomPayload.func_73279_a(SourceFile:61)
[22:55:58 INFO]: Client> at net.minecraft.network.MemoryConnection.func_74428_b(MemoryConnection.java:89)
[22:55:58 INFO]: Client> at net.minecraft.network.NetServerHandler.func_72570_d(NetServerHandler.java:141)
[22:55:58 INFO]: Client> at net.minecraft.network.NetworkListenThread.func_71747_b(NetworkListenThread.java:54)
[22:55:58 INFO]: Client> at net.minecraft.server.integrated.IntegratedServerListenThread.func_71747_b(IntegratedServerListenThread.java:109)
[22:55:58 INFO]: Client> at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:691)
[22:55:58 INFO]: Client> at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:587)
[22:55:58 INFO]: Client> at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:129)
[22:55:58 INFO]: Client> at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:484)
[22:55:58 INFO]: Client> at net.minecraft.server.ThreadMinecraftServer.run(SourceFile:583)
Thanks for clarifying. Did you make sure you installed the 64bit version of the Visual C++ runtime? Because that and the Windows kernel are really the only dependencies in that DLL. If you did, just for the sake of it could you try installing the 32bit version, too, and see what happens? Sorry for the inconvenience.
Oooh, a heat and cooling mechanic would be neat : P
In reality you can't fill a room with computers that are running 24/7 and expect them to live very long unless you provide sufficient cooling.
:3
Hah, water cooled computers? I don't think these computers are powerful enough generate that amount of heat though. They're much weaker than your average tablet device, and those don't need cooling. Still, a nice idea I'll keep in mind.
Hah, water cooled computers? I don't think these computers are powerful enough generate that amount of heat though. They're much weaker than your average tablet device, and those don't need cooling. Still, a nice idea I'll keep in mind.
But old computers were hardly as efficient as a modern tablet. : P
But this would be one of the cherries on top. You probably have more important things to work on at the moment. ^-^
If it's wireless (smartphone like) this could be achieved via an expansion card that does the "server" part and some client handheld items, I suppose.
If you could pull this sort of thing off, securely, that would be epic. I use CC to do security lockdowns on my base. If I can remotely trigger the lockdown using a handheld device, that'd be awesome.
Further, the mod supported in my signature adds stargates, with CC support. This setup could be used to add in GDOs for those looking to recreate the SGC...
Hi, I just wanted to say that in principle, I think your mod is really cool. However, your decision to use native libraries makes it a pretty much total non start for modpacks. Just so you know. Even if we could get OSX compiled for you, it's unlikely 3rd party hosts will ever set that up and it complicates our distribution.
In theory, it should be easy to bundle the libraries for all three platforms into the same package. Outside of Windows, dependencies could be statically linked. But that's just in theory. I've been bitten many times by system dependencies. Perhaps persistence could be made optional? There are a lot of other interesting aspects of this mod. Not the least of which it being open-source.
In theory, it should be easy to bundle the libraries for all three platforms into the same package. Outside of Windows, dependencies could be statically linked. But that's just in theory. I've been bitten many times by system dependencies. Perhaps persistence could be made optional? There are a lot of other interesting aspects of this mod. Not the least of which it being open-source.
Using a non-persistent fallback if the native library isn't available is actually a pretty nice idea, I'll just have to make this very clear to the player so there won't be any "they reboot all the time" reports.
Using a non-persistent fallback if the native library isn't available is actually a pretty nice idea, I'll just have to make this very clear to the player so there won't be any "they reboot all the time" reports.
That should work with playing on a server with the libraries even if the client doesn't have them right?
I wanted to hack around with the source code, partly to learn scala, partly just to have fun. Unfortunately, I've become frustrated trying to figure out how to get things to build. I've got Eclipse 4.2 with Gradle integration and forge set up. I cloned the github repo into the src/main/scala directory. I then installed the Scala IDE for Eclipse. Unfortunately, I can't get Eclipse to treat the code as Scala (just Java). After some googling, I enabled "Scala Nature" on the project, but it still does not seem to work. There seems to be little documentation surrounding all of this. Any help is appreciated. Thanks!
Well, currently you cannot place a keyboard on the front face of a screen. It simply wont let you.
What you could do is, instead of preventing this, when you try to attach it to the front of a screen, render the keyboard as shown below while still linking it with the screen that was clicked.
I'm talking about this in terms of keyboard placement:
It'd be nice to be able to make a little "office space" like this, but without using screens as a desk of course. : P
And this obviously doesn't work since the keyboard is linked to the downwards facing screens.
I also noticed that sometimes when placing screens facing up or down they will stop linking after a few seconds causing oddness like this:
Railcraft Boiler Calculator
They don't because in the current implementation that wouldn't make sense and just be confusing ("why isn't this keyboard working?"). That would obviously have to change, yes. Clicking on front of the screen to place it and make the association obvious is great idea, I guess that's how I'll do it.
Damn. Just to check, are you 100% sure the screens are all oriented the same way? Do they connect after exiting and going back into the game?
Creator of OpenComputers. My Twitter. My Patreon.
They do not connect after exiting. And they look like they're all pointing upwards. I have no way of checking their actual orientation.
It doesn't always happen, but all of a sudden screens stop connecting to existing ones that were placed a while ago.
It only seems to be an issue with bigger screens.
Here's a quick video I recorded which might better illustrate what happens:
Railcraft Boiler Calculator
I did not mean that the keyboard has to be placed like I suggested. It is merely a way to create a visually pleasing "office space" or similar with the screen and keyboard as I showed in the first screenshot while still being able to use them. But I'd still want you to be able to put the keyboard on the side or on top of the screen like you do right now.
I'd still want the gui to open like it does now when either the keyboard or screen is activated.
Railcraft Boiler Calculator
Ah, that clears it up. They do have the wrong orientation (i.e. yaw, which controls how the text displayed on them is rotated). The screen's "up" direction (screen-space wise, i.e. where the top of the displayed text is) depends on the way you're facing when placing it, not its environment. So the screens you place at ~0:35 have an "up" direction 90 degrees counterclockwise of that of the other screens, and won't connect because of that.
I could ignore the yaw, but the issue with that is: which of the two orientations to use? That of the larger part, that of the most recently placed one? So I'd rather keep it like it is now.
Creator of OpenComputers. My Twitter. My Patreon.
Oh right, I see what happens. Maybe a subtle marker on the texture so you can tell which way "up" is would decrease confusion?
Railcraft Boiler Calculator
Something along those lines. I think I have a nice non-intrusive solution that won't require me re-writing anything: an overlay on screens indicating their yaw only shown when the player is holding a matching screen block. Will have to try it out to see how it looks.
Creator of OpenComputers. My Twitter. My Patreon.
Thanks for clarifying. Did you make sure you installed the 64bit version of the Visual C++ runtime? Because that and the Windows kernel are really the only dependencies in that DLL. If you did, just for the sake of it could you try installing the 32bit version, too, and see what happens? Sorry for the inconvenience.
Creator of OpenComputers. My Twitter. My Patreon.
In reality you can't fill a room with computers that are running 24/7 and expect them to live very long unless you provide sufficient cooling.
:3
Railcraft Boiler Calculator
Hah, water cooled computers? I don't think these computers are powerful enough generate that amount of heat though. They're much weaker than your average tablet device, and those don't need cooling. Still, a nice idea I'll keep in mind.
Well, this is odd, but as long as it works... I'll add a note on that to the opening post.
Creator of OpenComputers. My Twitter. My Patreon.
But old computers were hardly as efficient as a modern tablet. : P
But this would be one of the cherries on top. You probably have more important things to work on at the moment. ^-^
Railcraft Boiler Calculator
If you could pull this sort of thing off, securely, that would be epic. I use CC to do security lockdowns on my base. If I can remotely trigger the lockdown using a handheld device, that'd be awesome.
Further, the mod supported in my signature adds stargates, with CC support. This setup could be used to add in GDOs for those looking to recreate the SGC...
I'm working on an open-source mod called Craft++. Check it out!
In theory, it should be easy to bundle the libraries for all three platforms into the same package. Outside of Windows, dependencies could be statically linked. But that's just in theory. I've been bitten many times by system dependencies. Perhaps persistence could be made optional? There are a lot of other interesting aspects of this mod. Not the least of which it being open-source.
Using a non-persistent fallback if the native library isn't available is actually a pretty nice idea, I'll just have to make this very clear to the player so there won't be any "they reboot all the time" reports.
Thanks, I've sent you the details via PM.
Creator of OpenComputers. My Twitter. My Patreon.
That should work with playing on a server with the libraries even if the client doesn't have them right?
Railcraft Boiler Calculator
Yes, that would remain unchanged, i.e. it will work as long as the server has the native library.
Creator of OpenComputers. My Twitter. My Patreon.
That is good for people to know. Since most dedicated servers are run on linux.
Railcraft Boiler Calculator