Random Chitchat 2012-2016

[ruediger]

I've never connected any kind of keyboard to any of my Pies, always worked through SSH. So it can be done.

As for multiboot, I think swapping the SD card is much easier than spending hours researching ways to do anything else.

Be careful with "high-speed SD card", the high-speed marking can mean anything, really. Always look for the card class ( = minimum guaranteed write speed, in megabytes / sec), declared average read and write speeds or, even better, actual speed tests done by people. I've seen some 2 MiB/sec cards labeled as high-speed.

Surely it "can be done" - But all my pi's so far per default didn't announced their name upon fetching their DHCP IP, so I had to always refer to the router for their IP - respectively "try the range".
Maybe its just my setup.
But I found it always most easiest to log in on terminal 2 and give it a fix IP under which I then was able to find them straight away.
Logging in and once typing "ifconfig eth0 192.168.33.2" was faster than loggin in on the routers website and maneuver to it's list of dhcp'ed devices for me.

Edit:
I do have 34 dhcp'ed devices in my network which change IP on each reboot. So searching for one specific really is a downer for me.

[DiamondToaster]

I wonder if I can create an AngelScript implementation of the scripting API. I was looking around and its a really nice language, its got near identical C++ syntax and is JIT/precompiled.

[xoft]

Again with all those other scripting languages! It's not so difficult to export the API, the most difficult thing to export is the callback / hook mechanism and to automate the entire API export (you don't want to write src/Bindings/Bindings.cpp by hand, do you? A megabyte of dense C++ code)

[sphinxc0re]

I looked a little bit into AngelScript and it's quite nice.

[DiamondToaster]

I may look into doing that, I feel as though AngelScript is a bit better at being object-oriented and is easier to manage dense code. I'll have to look into how the Bindings.cpp files is generated.

[NiLSPACE]

Keep in mind that an extra scripting language means doubling the work when exporting manual bindings.

[DiamondToaster]

I suppose so. It shouldn't be too hard to export though right? And two scripting languages, one that is basically scriptable C++. It could make plugin development easier, especially for someone like me who doesn't really like touching metatables.

[NiLSPACE]

I'm still not really convinced if we need a second scripting language. The only really advantage I can see is that maybe other people will write MCServer plugins because they can write a plugin in the language they prefer the most.

There are quite allot of things you also need to think of. For example what if a plugin folder has both Lua and AngelScript files. Will we register it as an Lua or an AngelScript plugin.
Also, what if an AngelScript plugin wants to communicate with a Lua plugin or backwards?

I think we should discuss the real advantages first to see if it's worth to go through the trouble.

EDIT:
btw you do know that we had a second language quite some time ago called Squirrel, but we dropped it because it was too much trouble keeping it up-to-date with the latest API.

[DiamondToaster]

Well, I was gonna just test it by myself unless other people really wanted a use for it, then I would release it if others wanted to try it. I would probably make a separate folder called ASPlugins to put the extra plugins that will be registered as AngelScript. I just want to experiment with it as it would also help me make a game in the future with the Urho3D engine, which uses AngelScript.

[NiLSPACE]

Ah, I was getting too serious

Having an extra folder called ASPlugins would look pretty ugly in my opinion, so it might be better to think of something else first

I do like the idea of a new scripting language if we can keep the amount of extra work as small as possible, and if it actualy has an advantage