Monday, April 3, 2017

Logging the Creation of a Beast -- the Good, the Bad, and the Template Metaprogramming.

Re: Monday, April 3, 2017

Postby Talvieno » Tue Apr 04, 2017 7:42 am

That post is bigger than your devlog. :lol: I'm already working on your KS update. Do I need to include part of this too? :P
Have a question? Send me a PM!
User avatar
Community Manager
Posts: 8178
Joined: Fri Apr 11, 2014 6:50 pm
Location: North GA, USA

Re: Monday, April 3, 2017

Postby JoshParnell » Tue Apr 04, 2017 7:45 am

Talvieno wrote:That post is bigger than your devlog. :lol: I'm already working on your KS update. Do I need to include part of this too? :P was fun. And productive :monkey: And no you don't :lol: I wrote it knowing full-well that few will read it, but that's ok!

Though I do hope some community members that think of themselves as not-so-inclined with respect to programming will glance at those mods and see how easy it will be to shape LT :D ...never too late to become a programmer...
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
User avatar
Posts: 4256
Joined: Sun Oct 07, 2012 3:06 pm
Location: Baton Rouge, LA

Re: Monday, April 3, 2017

Postby Scroey » Tue Apr 04, 2017 12:27 pm

Seeing how easy you made it look like I am seriously considering picking it up as a hobby whenever LT finally comes upon us to soak up all of our free time for the rest of our existence. I already have some experience in Python and shell, and at least read a bit of Lua to resolve conflicts in Factorio mods. Can't be that hard to adapt.

That really looked as painless as it was powerful. I can barely wait to get my hands on it!

Well, I have been waiting for 5 years now, I can certainly wait one more, or three... I think five would be a stretch.
Posts: 9
Joined: Sat Dec 08, 2012 11:55 am

Re: Monday, April 3, 2017

Postby mcsven » Tue Apr 04, 2017 1:36 pm

Wow, buy one dev log and get another one free! :o

A treat to get the inside scoop as always Josh, great job. I must also commend you on your written communication skills: writing long posts that are readable and still informal and chatty is a real skill.

PS: Scroey, that's some A-grade lurking. Kudos.
Last edited by mcsven on Tue Apr 04, 2017 2:23 pm, edited 1 time in total.
User avatar
Posts: 627
Joined: Sun Mar 03, 2013 5:41 am

Re: Monday, April 3, 2017

Postby RedDwarfMining » Tue Apr 04, 2017 2:11 pm

:o :o

Wow! Fantastic update! :thumbup:

I play EVE and there isn't a Collision Detection system to be found! Still enjoy it. though....watching my ship warp through a station is a bit over the top!

I'd rather have thousands of entities in LT, than a perfect CD system...I think...don't want to sacrifice all the goodies. ?
User avatar
Posts: 88
Joined: Tue Nov 18, 2014 1:26 pm

Re: Monday, April 3, 2017

Postby trashcash » Tue Apr 04, 2017 2:16 pm

I'm usually lurking, so generally: these weekly dev logs are great josh! Very inspirational. Wish you all the best for the future of this beautifull game!!

Since i'm no programmer, and all this k-d tree stuff generated more questions, heres a random blogpost by some fellow that explains the concept with clickable examples. For any other confused non programming people. :think:
Posts: 8
Joined: Wed Jun 25, 2014 10:21 am

Re: Monday, April 3, 2017

Postby N810 » Tue Apr 04, 2017 2:24 pm

Checked out the demo...
k-d tree's seem Quite promising indeed. :geek:
I wonder if this might me the fast solution Josh is looking for ?
"A sufficiently advanced technology is indistinguishable from magic."
- Arthur C. Clarke
User avatar
Posts: 688
Joined: Mon Nov 26, 2012 3:20 pm

Re: Monday, April 3, 2017

Postby Zanteogo » Tue Apr 04, 2017 2:26 pm

Thank you Josh and Talvieno for the update.
My Signature
User avatar
Rear Admiral
Posts: 1723
Joined: Fri Apr 18, 2014 8:33 am
Location: ※League of the 20,000 Planets※

Re: Monday, April 3, 2017

Postby Silverware » Tue Apr 04, 2017 3:20 pm

Lol, Josh you dick. :V
Tal, you now need to put that post as a full diary like thing. :V

Josh, I 112% agree that getting collisions out of the way early is the right move. They are crucial to so many parts of gameplay, and hacky implementations are the worst.
It's an incredibly CPU heavy set of code too, so it needs to be nailed to keep performance good. I assume you are therefore doing at least most of it in C directly.

Clean and fast collision detection means we can have MORE things in a map at once. The faster this is, the bigger LT maps can be, and the more interesting stuff can be in them.
A max fleet of six fighters would be boring. With faster collision detection this could become a fleet of 60 or 600. :D

Also, dem scripts... I'm going to have to learn Lua, or break Lua to take JS formatting instead. ;3
User avatar
Vice Admiral
Posts: 2954
Joined: Sun Sep 07, 2014 3:23 pm
Location: Goattown-Three, Sigma Six, Goat Space

Re: Monday, April 3, 2017

Postby Flatfingers » Tue Apr 04, 2017 3:52 pm

Wow. Thank you again, Josh, for taking the time to write what, as mcsven said, combined detail with clarity.

On collision detection, it seems like what I was missing was the knowledge that it's doing a lot more than just "ship hit station?"; this is a system that covers many kinds of physical interactions. As such, it's more fundamental than I thought.

This Court finds for the defense. Next case, please! :lol:

On modding, of course I understand that it can only be made so easy. I would even argue for caution in making any special effort to simplify it beyond what you're already doing through the basic design of the scripting interface. There should, I think, be a balance of responsibility there.

I mostly followed the examples, I think. And I'm glad to hear they helped a little with your own planning; that's really all I hoped for. The note that debugging/profiling tools will work is especially welcome, though, as well as the by-design split between ECS-modifying and generally-modifying functions/data. I'm hopeful that between these, we (I) won't shoot ourselves (myself) in the foot too often.

At the risk of getting beaten up by forumers who'd rather you were coding, though 8-) , what I keyed on most was your distinction between extending scripts/data and replacing them. I understand that you've taken steps to make extending easy -- I can see that in your example code. It's modifying (or even suppressing) functionality that I'm wondering about.

What if there's a feature that is altered by several mods? How will hierarchy be enforced? With a BethSoft "loading order" paradigm or something else (and where would that control live)? Also, if there's a whole feature set that needs to be disabled (perhaps for a really big functionality change of some kind), will there be a simple way to do that, and will modders and mod-users be alerted that any code with a dependency on the disabled functions may break?

Enough! :D The judge must retire to his chambers for the nonce... at most, two nonces.
User avatar
Vice Admiral
Posts: 4533
Joined: Sat Nov 24, 2012 12:45 am

Re: Monday, April 3, 2017

Postby Damocles » Wed Apr 05, 2017 1:54 am

Josh: Do you do calculations (entities, physics, events) for every render frame (eg variable time), or do you have a constant time internal logic frame / tick with the visualizations (positions) interpolated for the actual rendering?

Since doing a physics query like 60 times a second (each render frame) sounds quite overkill. And when the framerate drops, the collective results of the physics calculations would change.

In my projects, I usually have a constant time logic calculation. Lets say 20 ticks per second, no matter the render speed.
The rendering itself gets an interpolated version of the changes.
User avatar
Lieutenant Commander
Posts: 117
Joined: Thu Jan 12, 2017 4:09 pm

Re: Monday, April 3, 2017

Postby 0111narwhalz » Wed Apr 05, 2017 2:10 am

I know Unity (yeah, I know) uses a clock measuring game-time. That is, no more than x seconds of ingame time may pass before a physics frame is calculated, even if it pushes the simulation ratio down (one second ingame might correspond to two seconds realtime, for instance). Some other engines do the same, so obviously it's a thing that is useful. Optimal? I dunno.
User avatar
Posts: 444
Joined: Mon Feb 01, 2016 11:40 pm

Re: Monday, April 3, 2017

Postby Employee 2-4601 » Wed Apr 05, 2017 2:23 am

Flatfingers wrote:What if there's a feature that is altered by several mods? How will hierarchy be enforced? With a BethSoft "loading order" paradigm or something else (and where would that control live)?
I've no idea what the BethSoft approach is, but a two-pronged solution I've seen before is:

(a) for mods to be able to specify a simple global priority (probably a number) for themselves so that a mod can broadly suggest that "I want my listeners to run before most others", "I don't care when my listeners run", etc...

(b) for mods to be able to manipulate (on a per-event basis) the order of all the listeners for that event. i.e. A given mod M1 which knows that it interacts with another mod M2 could explicitly say that M1's listener for event E must be processed before M2's listener for event E, simply by manipulating a list of that event's listeners.

In combination, all listeners for an event are firstly registered, and ordered according to the global priorities of the mods providing them. Once all the listeners are known, all mods then get the opportunity to rearrange that sequence. At that point the sequence is final, and listeners for the event will always be processed in that order.
Last edited by Employee 2-4601 on Wed Apr 05, 2017 4:39 am, edited 5 times in total.
Employee 2-4601
Lieutenant Commander
Posts: 134
Joined: Sat Dec 13, 2014 7:19 am

Re: Monday, April 3, 2017

Postby Cornflakes_91 » Wed Apr 05, 2017 2:51 am

bethsoft approach:
All packages are loaded in order and packets that are loaded later can overwrite what earlier packets did.

The problem is already solved when mods know beforehand with what other mods they interact, because then theres code handling that special collision.

Problems arise when multiple mods that dont know about each other change the same base code.

One mod sets x to 1, another one says that x should be 2.
What do you do now?
Its a glorious, potentially infinite collision point, mess of mods modifying the same vanilla/prequisite code with no clear order who gets precedence.
User avatar
Posts: 9173
Joined: Wed Mar 06, 2013 1:53 am
Location: Austria

Re: Monday, April 3, 2017

Postby Employee 2-4601 » Wed Apr 05, 2017 4:23 am

Cornflakes_91 wrote:bethsoft approach: All packages are loaded in order
Which order?

If a package which needs to modify other packages needs to be loaded after those other packages in order to do so, then there needs to be a way for the first package to manipulate the load order to ensure that it is loaded after them?

Cornflakes_91 wrote:One mod sets x to 1, another one says that x should be 2.
What do you do now?
Well one of them 'wins'. I honestly don't think there's any purpose in worrying about conflicts between mods. If mods have complete access to the LT internals, then conflicts can occur. Trying to prevent that will create overhead at minimum, or might result in mods being heavily restricted.
Employee 2-4601
Lieutenant Commander
Posts: 134
Joined: Sat Dec 13, 2014 7:19 am


Return to Dev Logs

Who is online

Users browsing this forum: Mike and 4 guests