Intro Hello World!

[Hybrid]

If you'll excuse my totally chuunibyou nickname:

• Name: Sumeet `Hybrid` Padavala
• Social: Github: github.com/hybrideagle, IRC: hybrideagle
• From: Bangalore, India
• Skills / Tools: Java, Minecraft, ROS, Node.js, Python, Machine Learning/Deep Learning/AI, Hadoop, Kubernetes
• Found via: GSoC 2017
• Interests: machine learning and AI(insert a thousand subtopics here), networking, procedural generation, aerial robotics, general automation, IoT, massively parallel systems(for the sheer awesomeness factor)
• Extra: Currently pursuing a CS undergraduate degree at PESU, Bangalore. Really likes Mr. Robot and Steins;Gate.

Note: I'm quite new to the whole programming scene, so my interests are all over the place. For the same reason, I'm don't think I know which part of Terasology I could best contribute to.

I've been looking through the code for a few days now, and from what I can see:

• The liquid system could use an overhaul.
• Maybe the CoreRegistry should be split up into different registries, with registration methods exposed as an API(one each for liquids, blocks, entities, etc)?
• The AI system desperately needs some love.
• Is there any sane way to restrict the types of objects allowed to go into the Context? It seems...wrong, for some reason, to be putting random objects in the Context(at least there's no weird reflection code though).

I've also got a few GSoC ideas, should I put them in suggestions?

 

[Cervator]

Heya @Hybrid and welcome!

• Yep liquids need work. There is an initial effort with the SimpleLiquids module that does basic water propagation when enabled.
• The Context stuff has another discussion thread over here if you're curious. It is meant to be cut into smaller pieces than the global CoreRegistry, but not so much by function as by, well, context
• AI definitely needs some love! And it is one of the GSOC items.

Feel free to post more GSOC ideas here, in the GSOC thread, or indeed in Suggestions - but for that last one do a bit of searching in that sub-forum and in our main repo on GitHub to see if there might be something out there already.

 

[manu3d]

If your interest is in AI I'd definitely recommend you stick to that unless your studies on the topic are already so intense you'd like something different.

Liquids could be as small or as big as a project as you'd like, starting from SimpleLiquids going all the way to an overhaul of the simulation aspects of the engine, i.e. implementing Sectors as Cervator has recommended in the past.

CoreRegistry is slated to be replaced by Contexts. The idea with Contexts so far is that they will still be pretty generic containers, but we could certainly structure them a bit more hierarchically, with the main context containing more specialized contexts as deep as we need them. You might want to talk to @Flo on these matters. Some progress has been made but the CoreRegistry is in so many places in Terasology it is something that takes time.

Welcome aboard!

 

[Hybrid]

Okay then, I'll just dump everything here for now, and move it when I have something substantial.
Questions:

• I'm really confused about this. Why do we not just use Urns for everything? Wouldn't using a class as key limit the Context to a single object? Should we put things in the Assets API, even when they really should be in a Context? Or is that the whole point? Do we want anything with an Urn to be globally accesible?
  
• Are Contexts and the Assets API meant for solving completely different problems?

Note: I don't really know much about the codebase yet, and most of this stuff is just shower thoughts.

• Can we design NUI interfaces declaratively? HTML, or something similar? YAML? CSS? Some sort of crazy custom template system?
  
• Multiple facades: Facades don't seem to actually do much. Alternatively, can we have one facade acting as a bridge for other facades? Maybe with a custom-built own protocol based on TCP/IPC? Or with injection?
  
• Communication API's: Give systems the ability to talk to each other through a pub/sub system. Use cases: Cameras, sensors.
• Global registries: Can we have some global registries for certain purposes, like Minecraft's BlockRegistry and ItemRegistry(I think that's what its called)? Or, can we move blocks into the Assets API?
  
• AI revamp: Well, this is a big one. Here's what I think we need here:
  1. Create a base Interface and/or ABC for behavior controller.
     
  2. Create components(with the Urn for the controller).
  3. Set up behavior controllers as assets.
     
  4. Identify a mechanism for getting the correct data from the Entity's surroundings into the related component, maybe as a set of simple predefined functions in an ABC.
  5. Identify a mechanism for controlling movement of the Entity.
     
  6. Create a system for running behavior controllers(at a fixed frequency?).
  7. Figure out a way to generate controllers at runtime, maybe from YAML files, or some kind of templating system(for including other java functions)? @synopia's jbt already does this to some extent(albeit with groovy), so integration shouldn't be too hard.
     
  8. Create more controllers for ease-of-use, NFA's, DFA's, and so on.
  9. (Maybe) Build a tool for visually programming behaviors.
  10. (Probably overkill) Add basic feed-forward neural networks.
  11. (Just for fun) Integrate Gooey into the console(yes, I'd add irc support just for having a chatbot around). Gooey could become our mascot

 

[manu3d]

@Hybrid: can you please move your last three post into 2-3 separate forum threads? It doesn't make sense to keep subjects as disparate as rendering/DAG and other architectural issues in the same thread.

 

[Hybrid]

I'm rewriting them right now, I'll move each when I'm done.