Return to “Dev Logs”

Post

Re: Monday, April 3, 2017

#31
Employee 2-4601 wrote: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?
Mod user's responsibility, these things are usually heavily emphasized in these kinds of mods. In the case of Bethesda games, ordering tools have also been made.
A good plan, violently executed now, is better than a perfect plan next week.

In magenta we trust
Post

Re: Monday, April 3, 2017

#32
JoshParnell wrote:The defense rests :roll:

(I didn't mean to write that much. Whoops. :ghost: )
It's back. :squirrel:
Oh yeah, it's back guys.
That old dev log feelin'. :mrgreen:
Don't give me a tl;dr. This is prime reading together with my morning coffee and an epic-track-of-the-day. :thumbup:
"omg such tech many efficiency WOW" ~ Josh Parnell
Post

Re: Monday, April 3, 2017

#33
This is some super exciting stuff!! Simple where it can be, yet powerful when it needs to be! Being able to write low-level C code is a huge plus and is a welcome addition. I'm very excited to see what people can come up with :) I'll definitely be playing around with this.
Baile nam Fonn wrote: It's back. :squirrel:
Oh yeah, it's back guys.
That old dev log feelin'. :mrgreen:
Couldn't agree with you more! I'm more excited about LT's future than ever before. I am also happy Josh was been able to put himself first and get back to where he is. It's important for his continued well-being, and we'll all be the better for it :)
Post

Re: Monday, April 3, 2017

#34
Employee 2-4601 wrote:
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?
packets dont decide, they get ordered by hand.

Employee 2-4601 wrote:
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.
thing is that we need reliable conflict resolution, simplest one is the bethsoft system, just manually order what loads.
when you just have race conditions you get the worst of both worlds, mods overwriting each other AND doing so without any predictable pattern.

the "best" would be to be able to control on a per-change basis which version wins.
let script A change variable B but not A
and let script B change variable A but not B
would be a hellova list to sort through once a few large mods start to collide
Post

Re: Monday, April 3, 2017

#35
Cornflakes_91 wrote:
Employee 2-4601 wrote:
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.
thing is that we need reliable conflict resolution, simplest one is the bethsoft system, just manually order what loads.
when you just have race conditions you get the worst of both worlds, mods overwriting each other AND doing so without any predictable pattern.
Oh, I'm not suggesting that execution sequences are arbitrary! Quite the opposite -- I wholeheartedly agree that there should be a consistent sequence every time an event fires.

When I say that one of the mods "wins" I'm not talking about race conditions. I'm saying that in accordance with whatever sequence has been arrived at by whatever method, one of the conflicting mods would always clobber the other(s) in a situation such as you described. It would always be the same winner, though.

If the first mod sets x to 1, and the second sets x to 2, then x ends up being 2.

I was merely trying to suggest that LT shouldn't care if multiple mods are all setting a particular value.
Cornflakes_91 wrote: the "best" would be to be able to control on a per-change basis which version wins.
let script A change variable B but not A
and let script B change variable A but not B
would be a hellova list to sort through once a few large mods start to collide
I disagree that LT should attempt to impose restrictions upon mods in this way. The overhead of enforcing such things (each and every time any code tries to set a variable or call a function?!) is surely not worth it. If two mods both set a given variable in response to a given event, the one which (always) runs last has the final say.

I do think (as I described earlier) that the sequence in which all listeners are processed for an event should be able to vary on a per-event basis, and that mods should be able to adjust that sequence for any event they are interested in, so that they can try to have the final say over other mods in cases where they know they need to do that.
Post

Re: Monday, April 3, 2017

#36
Cornflakes_91 wrote:
Employee 2-4601 wrote:
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?
packets dont decide, they get ordered by hand.
What? Are we all talking about the same packets? :lol:
Automation engineer, lateral thinker, soldier, addicted to music, books and gaming.
Nothing to see here
Flatfingers wrote: 23.01.2017: "Show me the smoldering corpse of Perfectionist Josh"
Post

Re: Monday, April 3, 2017

#37
Employee 2-4601 wrote:
Cornflakes_91 wrote: the "best" would be to be able to control on a per-change basis which version wins.
let script A change variable B but not A
and let script B change variable A but not B
would be a hellova list to sort through once a few large mods start to collide
I disagree that LT should attempt to impose restrictions upon mods in this way. The overhead of enforcing such things (each and every time any code tries to set a variable or call a function?!) is surely not worth it. If two mods both set a given variable in response to a given event, the one which (always) runs last has the final say.

why is that a restriction on mods?
its more freedom for modding because one can mix and match between mod features as you like.
like the changed weapon mechanics of mod A but like mod B's ship designs better than A's?
give B the go for overriding the ship designs and A for overriding weapon mechanics.

and how is one of them not "always run(s)"ning?
either they have registered for an event or they dont.
there is no between.
Employee 2-4601 wrote: I do think (as I described earlier) that the sequence in which all listeners are processed for an event should be able to vary on a per-event basis, and that mods should be able to adjust that sequence for any event they are interested in, so that they can try to have the final say over other mods in cases where they know they need to do that.
modded script files replace functions/values once, at initialisation time.

you dont evaluate all the script files every time a function is called.
that would be storage IO and processing waste deluxe.

and if multiple files conflict on something it gets displayed to the user and the user can decide which file is the one that gets priority.

also, yes, totally let the mod decide that it MUST run at a specific position in the queue, that totally wont lead to conflicts with other mods which demand exactly the same

the user is the king of that, mods can ASK for a specific place in the queue, but the user decides on if thats acually granted.
Post

Re: Monday, April 3, 2017

#38
This communication thing is hard. I fear we are continually misinterpreting one another.
Cornflakes_91 wrote:the "best" would be to be able to control on a per-change basis which version wins.
let script A change variable B but not A
and let script B change variable A but not B
I read this as suggesting that when script A sets variable A LT would do a permission check, find that script A did not have permission to set variable A, and ignore the statement. And if script A sets variable B it would likewise check permissions and allow the statement to execute. It's not clear to me what you actually meant, but this is what I was referring to when I wrote:
I disagree that LT should attempt to impose restrictions upon mods in this way. The overhead of enforcing such things (each and every time any code tries to set a variable or call a function?!) is surely not worth it.
Cornflakes_91 wrote:you dont evaluate all the script files every time a function is called.
that would be storage IO and processing waste deluxe.
Indeed, and I was ambiguous here. When I wrote
the sequence in which all listeners are processed for an event should be able to vary on a per-event basis
I meant "per-event" to mean each independent type of event that exists in LT, rather than each time a given type of event is triggered in the game. Firing a weapon might be an event, and Mod A might have priority over Mod B for that event. Receiving a communication might be an event, and Mod B might have priority over Mod A for that event. These priorities would be determined once only, and used every time those events are triggered.
and if multiple files conflict on something it gets displayed to the user and the user can decide which file is the one that gets priority.
For anything other than "Mod A has priority over Mod B in every situation" making the user decide would be a nightmare for the average user, and installation instructions for mods would be painful. I have no qualms with the user being able to decide (and indeed having the ultimate decision in the matter), but there's no way they should be prompted to do so by default.
also, yes, totally let the mod decide that it MUST run at a specific position in the queue, that totally wont lead to conflicts with other mods which demand exactly the same
Sarcasm I presume.

I am talking about mod authors knowing that their mod interacts in particular ways with other specific mods, and making sure that their mod acts before or after those other mods appropriately. I'm not talking about "Mod A's listener for Event X runs 3rd"; I'm talking about "Mod A's listener for Event X runs before Mod B's listener for Event X".

(In fairness I am implying a mod could try to say it wants to run 3rd, but that wasn't something I was imagining; although wanting to run "first" or "last" is a similar and somewhat more likely (even if naive) desire on the part of a mod author. Obviously they may not get their wish if they try to do that.)

And yes, there can inevitably be unresolvable conflicts between mods; mods that simply can't and won't work together. LT shouldn't care. Give the mods the tools to sort out their own problems if possible & reasonable, but don't expend effort at run-time trying to police them.
the user is the king of that, mods can ASK for a specific place in the queue, but the user decides on if thats acually granted.
I'm all for the user having the final say, but by default I say let the mods do what they want to do, because the mod authors probably know more about the conflicts than the users do. Allow the users to override the mods, but don't make the users need to override the mods.
Last edited by Employee 2-4601 on Fri Apr 07, 2017 6:03 am, edited 3 times in total.
Post

Re: Monday, April 3, 2017

#39
JanB1 wrote:What? Are we all talking about the same packets? :lol:
Both "packet" and "package" were mentioned, and "package" sounded more like a mod to me, so I thought "packet" might have been a typo? To me "packet" is networking talk, and I've barely played a BethSoft game since Skynet, so I don't know what they might mean by it.
Post

Re: Monday, April 3, 2017

#40
Employee 2-4601 wrote:
JanB1 wrote:What? Are we all talking about the same packets? :lol:
Both "packet" and "package" were mentioned, and "package" sounded more like a mod to me, so I thought "packet" might have been a typo? To me "packet" is networking talk, and I've barely played a BethSoft game since Skynet, so I don't know what they might mean by it.
That's why I was asking. :D
Automation engineer, lateral thinker, soldier, addicted to music, books and gaming.
Nothing to see here
Flatfingers wrote: 23.01.2017: "Show me the smoldering corpse of Perfectionist Josh"
Post

Re: Monday, April 3, 2017

#41
Admittedly if lua provides macros which are expanded at compile-time ala lisp, and it was reasonable to recompile all mod code whenever permission changes were made, then permission-checking overheads could simply be compiled away. It would be necessary to perform all the permission-needing actions indirectly via the macros (unless read macros are also an option), but the compiled code could simply not contain the statements that were not permitted, and the statements which were permitted would be inlined in place of the macro call.

I'm not convinced that would be a good idea, but it might be possible.
Post

Re: Monday, April 3, 2017

#42
Concerning mod conflict:

First, if you haven't already, please prime yourself by looking at the example mods that I gave in the latter part of this post.

Notice that, the way I have structured mods and game logic in general is in such a way as to absolutely minimize mod conflicts. Even thought the last mod (Ancestry) adds a new section to part of the information UI for a 'Player,' and even adds new data to a class in C, it will not conflict with other mods that do so, because it simply inserts itself as a callback. As much logic as possible will be written in this manner. Adding new behaviors, pieces of UI, etc. will be virtually conflict-free, although combinations of added behaviors may make for strange final results, despite each mod 'working as intended.'

For mods that need to destructively modify existing logic, there are several approaches: first, one can flat-out override the game's files. E.g. ai/moveto.lua can be replaced with your own, upgraded version of movement AI. Recommended only as a last-resort. By replacing the file, you are saying "I am fundamentally changing how AI performs the MoveTo command." By definition, this means another mod that tries to overwrite the same file is a non-resolvable conflict. You shouldn't be able to run two mods at once that say "I am fundamentally changing how the AI performs the MoveTo command." There is no well-defined operation to resolve such a conflict. Despite that, LT will still let you run them, and will resort to TES-style mod-order resolution. It will be clearly marked for you that the mods conflict (since it's trivial to see that two mods try to overwrite the same file). You will be able to change the load order. In these cases, I will not try to provide any special merging logic, because IMO it is not the job of the game to do so :P Again, if two mods genuinely have such different ideas of what MoveTo should look like that they need to completely override the default, then they are incompatible.

Now...changing the details of specific pieces of, e.g., MoveTo, is still possible without overriding the function! Mechanisms for doing so: constant data and callbacks. You saw examples of both in those example mods. If you want to change how close MoveTo gets to the target, this will surely be a constant, not hard-coded into the script. So you simply make your mod change the value of said constant, just like I did with the drag-removal mod. If you need to do other things, I will insert as many 'hooks' as possible into the game so that you can register callbacks to change behavior. For example, AI.MoveTo.onCalculatePath(path) might be a hook that gets called when MoveTo has calculated a pathfinding solution to the target. If your mod registers a callback here, it can change path, so you could, for example, optimize the pathfinding / make it smarter / make it take into account some new navigation device that your mod introduces, and you can do so just fine without overriding the function itself. All of this comes very naturally when you start thinking about game logic as being comprised of events that trigger callbacks. The logic will already be designed in such a fashion.

Finally, as a midpoint between the above techniques, since we're talking about Lua here, you can actually override helper functions in a particular script without overriding the entire script (provided I provide access to the function). So MoveTo might be comprised of several sub-functions that run depending on the state of the MoveTo command: findPath(), flyTo(), jumpTo(), finalApproach(), etc (although these might also be factored out as separate AI routines altogether). For the sake of discussion, let's say they are exposed helper functions. Your mod can override a single sub-function of MoveTo by doing something like AI.MoveTo.flyTo = betterFlyTo, where betterFlyTo is a function that your mod defined. This is very similar to overriding constant data, except that the data happens to be functions :) Now another mod may do the same but instead override jumpTo, and this is generally OK, since you've both modified different parts of the overall script. This is really the only way that it makes sense for two mods to destructively modify the same script, and indeed, the engine will allow it! That's the absolute best I can offer...!

With all of this power, modders should be able to write really clean mods. If and when they don't, I leave it to them to resolve the conflicts :ghost:
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: Monday, April 3, 2017

#44
That all sounds good, thanks Josh. It's clear from this and the earlier examples that mods will have a lot of access and power, so I'm excited by the potential that brings.

The aspect I was discussing which you didn't cover is the order in which callbacks are invoked for hooks/events. When multiple mods register callbacks for a given hook, would the mods be able to determine the sequence in which those callbacks will be called by LT? Can Mod A say "for this particular hook I know it's important that I run really early" and adjust its position in the callback sequence (perhaps relative to the position of other named mods) for that specific hook, without the mod needing to have a high priority in the general load order?

I was imagining a two-pass system whereby all code registers the callbacks they need, and subsequently all code gets a chance to manipulate those registered callback sequences.

Online Now

Users browsing this forum: charles and 1 guest

cron