Talvieno wrote:That post is bigger than your devlog. I'm already working on your KS update. Do I need to include part of this too?

Yeah...it was fun. And productive And no you don't 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 ...never too late to become a programmer...

“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford

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.

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.

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.

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.

Also, dem scripts... I'm going to have to learn Lua, or break Lua to take JS formatting instead. ;3

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!

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 , 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! The judge must retire to his chambers for the nonce... at most, two nonces.

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.

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.

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.

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.

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.