Is it possible to require a file from outside of the current script directory? (client/server/etc)

[vocal timber]

Basically I currently have config files that set up a number of constants for use in the different client/server/startup scripts but it's becoming a pain having 3 different config.js files (one in startup_scripts, one in client_scripts and one in server_scripts). They all contain the exact same information.

Is there any way I could move this config file to the directory above (just the kubejs directory or wherever really) and load it in within each respective side script? I'm using forge 1.16.5 if that changes anything.

Neither require() nor import seem to work

[night igloo]

Once your ticket has been resolved, please close it with </ticket close:1054771505520717835> command!

[cloud cliff]

if you want to use the same information in all 3 script types, you can save them in the global variable inside the startup scripts

you can do something like

global.my_fancy_objects = {
  test: 'hello',
  count: 3
}

and that will be available to call and modify from any script

[vocal timber]

Oh that's awesome, I just read another post about their being something global but I was mistakenly creating a global_script folder to see if that works haha.

Do I have to use global.myobject.property to access?

[cloud cliff]

no you can just use global.my_fancy_objects.test from my example

if thats what you implied, yes

xD

[vocal timber]

Yeah thats what I had meant aha, that's amazing. Thank you! I just tested and it seems to work exactly as I hoped

[cloud cliff]

^^

[vocal timber]

Could you in theory write functions inside global too? Say for example you had a method you wanted to call in both client and server scripts (cant think of an example off the top of my head)

Doing something like this?

  doSomething() {
    console.log('something')
  }
}```

Then call global.helperFunctions.doSomething() inside the script folders?

[cloud cliff]

i think that should work

i havent tried

[bold leaf]

yes it works

you can put literally anything you want into global

kubejs even puts the jei runtime into there

[humble hazel]

I've use global for functions all the time, it helps for easy modification of startup event callbacks on script reload.

[vocal timber]

That's awesome, I figured it would. I've been using objects as "classes" of sorts to help organise my code

  helperFunction()
  {
    console.log(1)
  }
}```

So it would be even cleaner if I could put them all into global

Awesome stuff

[night igloo]

Ticket closed!

[vocal timber]

Can you elaborate on this?

[bold leaf]

global.jeiRuntime is the jei runtime, which can be used to hide items/recipes/whatever while the game is running

[vocal timber]

So you can modify things without needing a reload?

[bold leaf]

yes, but its a tad complicated
and needs to be done client side

[vocal timber]

I imagine it won't persist after the game is closed? Still really interesting, I'll have a little look into it. Appreciate the pointer!

[cloud cliff]

realtime changes?

[bold leaf]

you need to reopen your inventory, but otherwise yes, its realtime

[bold leaf]

it doesnt, you need to run it each time (just like the jei hide events)

🤔 the jei hide events use the runtime.. so could you save the event somewhere and just keep using it

why has no one tried that before

[cloud cliff]

i wasnt even made aware of this lol

as far as i knew global was just an empty thing that you could populate xD

[vocal timber]

Coupled with gamestages you could probably do some pretty interesting stuff, this changes everything 😄

[bold leaf]

dont even need gamestages
vanilla allows you to lock crafting stuff behind advacements, tho its a little annoying to work with cause its vanilla..

[humble hazel]

You can combine global with JsonIO, to save data between game sessions, although functions would not be included in that.

[vocal timber]

@bold leaf That's super interesting

@humble hazel Yeah I've been using JsonIO for loads at the minute, most of my new items are saved in JSON files, it's easier than calling event.create on the item/block registery over and over

I never considered writing to JSON files though, could open up a lot of new avenues

[cloud cliff]

wait how do you mean that?

[bold leaf]

they recreated jsonthings probably

[cloud cliff]

i dunno what that is

but i didnt understand the "creating items over and over" bit

they only get created once

when you launch the game

[humble hazel]

I think they mean rather than having a huge JS script with event.create called 10-50 times filling up the size of a single file, instead they have 10-50 files, each one containing an item they want made

At least that’s my guess

[vocal timber]

Yeah pretty much that, although I have multiple items per JSON file in groups. So I'd have food.json with all my food items or currency.json with coins/gold bars or whatever

Small example I've just rewritten thanks to this thread

    // Food
    JsonIO.read('kubejs/config/items/food/uncooked.json'),
    JsonIO.read('kubejs/config/items/food/ingredients.json'),

    // Misc
    JsonIO.read('kubejs/config/items/misc.json'),
)```

[cloud cliff]

for just normal items with nothing in particular, you can just make a list and then go through it, 1-2 lines

[vocal timber]

That creates an object on global that loads in and combines all those JSON files into a single object

    {
        Object.keys(global.register_items).forEach(id => {
            var item = global.register_items[id],
                e = event.create(id)

            if(item.name) e.displayName(item.name)
            if(item.texture) e.texture(item.texture)
            if(item.max_stack) e.maxStackSize(item.max_stack)

            if(item.tooltip) {
                item.tooltip.forEach(tip => {
                    e.tooltip(Text.of(tip).darkGray())
                })
            }

            if(item.food) {
                e.food(food => {
                    if(item.food.hunger) food.hunger(item.food.hunger)
                    if(item.food.saturation) food.hunger(item.food.saturation)
                })
            }
        });
    },```

[cloud cliff]

display name and texture

[vocal timber]

I call registerItems in the item.registery event

With the pack I'm building it's easier for me to have access to an object holding all the items, because the JSON stores things about the items KubeJS doesnt. For example in my food.json I also have sell price/seasons a crop can grow in and stuff like that

So if I ever need to know the sell price of an item I can just write global.item_registry[item_id].sell_price

[cloud cliff]

i suppose that makes sense

interesting approach, first time i see it :D

dont take it in a bad way

[vocal timber]

I dunno, maybe it doesnt, but I find it a lot easier to read a long JSON file than I do a JS one haha. Plus it was fun to code ^_^

[cloud cliff]