Ars Énergistique

[rain stirrup]

i'd rather there was some way for it to use both the items and the source

i guess a mixin would do? 😄

also this seems to work just fine

[distant lichen]

bruh

[rain stirrup]

i'm using a filtered interface in place of a source jar for the apparatus

[distant lichen]

the enchanting apparatus can use source

[rain stirrup]

it CAN?

[distant lichen]

just only up to 1 jar

yea a few recipes in Ars Omega use like 1/2 a jar of source each

people always complain about them too lol

[rain stirrup]

ahh

[distant lichen]

so I suggest you go light on making the cell recipe annoying

source acceptor can be complicated

[rain stirrup]

let's say 2,000 source per cell

[distant lichen]

and 10,000 for the source acceptor?

[rain stirrup]

even more

[distant lichen]

... won't work

since enchanting apparatus can only use 1 jar

[rain stirrup]

mixinmixinmixin

[distant lichen]

or you could do a mixin for that I guess

[rain stirrup]

i'm tempted

[distant lichen]

well, I'm not putting in that kind of effort to make a recipe marginally more expensive

I'd rather spend my time fixing the relay bug, and in the future helping backport the mod to 1.19

[rain stirrup]

the acceptor really should be kind of an endgame thing given how easy it could potentially be to power an ME network just using source

[distant lichen]

counterpoint, imagine how easy it could potentially be to power an ME network with just RF

[rain stirrup]

that's

already the standard

[distant lichen]

that's my point lol

so why does the magic route have to be harder?

[rain stirrup]

yeah, good point i suppose

10k source it is then

[distant lichen]

I say if someone wants to go full magic it's not much different than full tech

isn't that the point? making AE2 accessible in an Ars-focused pack

of the source acceptor anyway

[rain stirrup]

yeah, you're right

[distant lichen]

the point of the source cell is just big number in small space go brrr

I'm like this close to finishing porting industria lol

[rain stirrup]

no worries

[distant lichen]

so what were we doing for documentation again?

[rain stirrup]

add a chapter in the Worn Notebook i suppose

eventually also a section in AE2's own guide

[distant lichen]

...to be honest I'm not sure how I'd write the entries

I should really just focus on one thing at a time lol

[rain stirrup]

it's alright, i don't mind trying out the documentation

[distant lichen]

I mean more in general

I'm trying to chat here with you and port one of my addons at the same time

bad idea

[rain stirrup]

one thing at a time, do your thing for now

[rain stirrup]

something just occurred to me regarding the P2P output voiding thing

it might be that P2P for things like this needs to be somewhat bidirectional, as in if you pipe something into an output tunnel it should still come back out via the one input

therefore i might simply need to copy over the buffer stuff you added to the input handler as well

will investigate tomorrow

[distant lichen]

I'm not sure I follow that logic

I thought item P2P only works in one direction

[rain stirrup]

that's what i need to double check pretty much

as in, does it work in only one direction or is it supposed to be a "1:N one way, N:1 the other" deal

considering that we're literally checking on the output cap if the input cap can accept something, it sounds reasonable

and it's a similar deal for the existing P2P tunnels if i'm not mistaken

in any case, i think i can take it from here

do you know what, i bet if i was to put a source jar directly against the input tunnel and try sending source to the output tunnel then it would actually go into that input jar instead of voiding

actually i might be chatting utter bollocks

yeah the FEP2PTunnelPart class indicates that the output is not meant to allow FE to be inserted into it

so actually canAcceptSource might need to return false on the output

[distant lichen]

I'd have to check though, I thought some things check can accept source when taking source

But yea if not I'll make it return false

And I'll fix the voiding today for sure

[rain stirrup]

i expect that returning false there would be all that's needed to fix it as long as it doesn't break anything

i fail to see what could possibly be calling canAcceptSource to determine whether to removeSource

[distant lichen]

you are correct and I will fix that

nevermind you already did

um

@rain stirrup you broke the splitter relay, now it gives source to the list of positions it needs to take source from...

(unless I'm dumb and it was already broken)

ME cell housing is, like, suuuper cheap

maybe minus the glass

[distant lichen]

I made some recipes and worn notebook entries, you don't have to keep them but I figured they might help

[rain stirrup]

i believe i asked about that one already and you said that the list should have been toPos instead of fromPos in one inject

[distant lichen]

... no

in the list of stale positions to remove

the transfer code didn't need to be touched

*main transfer code

that did the actual transfers

[rain stirrup]

uhh

[distant lichen]

aaanyway, I already fixed the issue

[rain stirrup]

alright

sorry 😅

[distant lichen]

I also created placeholder recipes but if they suck you can change them

[rain stirrup]

was out of the scope of the PR but sure, no worries

by the way, ./gradlew spotlessApply

now i go back to sleep

[distant lichen]

... true but IDK if it's possible to make a PR based on a PR

[distant lichen]

I'll be honest I have no idea what that does

oooh, fixes formatting

ok

[rain stirrup]

that's not necessary, you'd just have to wait until the first PR gets merged and then open another

[rain stirrup]

anyways, i can't think of anything that's left to do for the PR. you think it's ready for merging?

[distant lichen]

those recipes look a little expensive but they work well enough

yea I imagine it's ready for merging

it adds and fixes everything it set out to

it all seems to work well

and if you merge it we can take a stab at a backport

[rain stirrup]

@distant lichen backport's done

[distant lichen]

... what

https://tenor.com/view/blinking-eyes-white-guy-blinking-meme-what-huh-gif-26334322

[rain stirrup]

only thing is i haven't been able to get the generated Patchouli pages to show up in 1.19 for some reason

[distant lichen]

I was... setting up my workspace to start doing a backport LOL

ok I'll pull your backport and look at the pages

[rain stirrup]

no worries

[distant lichen]

(or you can just not datagen them)

lol

[rain stirrup]

they do get generated, they just don't show up

not sure why

[distant lichen]

oh

ooooh

you need to define the book

I don't remember exactly but you need to make the book under data and it has a setting that says it extends the worn notebook

[rain stirrup]

in any case feel free to give it a spin in general and see if i accidentally broke anything else

[distant lichen]

I have... no idea how to datagen that though

can we just make it manually?

it's only the one to explain that there's a patchouli book

[rain stirrup]

fuck it, sure

[distant lichen]

should never need to be changed

... I think the rest of the stuff also needs to be in data but IDK for sure

[rain stirrup]

on this version the book is under assets rather than data

[distant lichen]

on 1.20, yes

they also changed it on 1.19?

[rain stirrup]

ah, sorry

it is data in 1.19, assets is 1.20

[distant lichen]

yea I figured

[rain stirrup]

patchouli is shit

[distant lichen]

I wouldn't know, I certainly couldn't make anything better

[rain stirrup]

there was mention in the past of AE2's new guide framework potentially becoming a standalone thing for other mods to use

[distant lichen]

that would be neat

um... I can't get the AE2 dependency to resolve

the others worked fine but AE2 just.... didn't

so now obv it won't compile

[rain stirrup]

eh? that's strange

[distant lichen]

I'm going to invalidate caches and try again

[rain stirrup]

yeah do that

[distant lichen]

I'm gonna get some lunch and then see how that went

[distant lichen]

yay it compiled this time

... I don't know how make the datagen place it in a different folder because IDK how the current patchouli provider is chosing the folder

also the recipes are in the ars_nouveu namespace, I think we can move them to the arseng one as well...

[distant lichen]

@rain stirrup I fixed the worn notebook entries

made a new PR with the changes (they're very minor)

[rain stirrup]

all good, will get to it later today

this timezone difference is mad btw lmao

[rain stirrup]

if i end up adding integration with this to MEGA Cells then the fucking 256M source cell would store 256 billion source as it stands

seems pretty ridiculous to be quite honest

[rain stirrup]

as was suggested by another AE2 add-on dev, here's some support for amethyst golems and certus quartz blocks!

[distant lichen]

Oh yea that is a good idea

[sly knot]

@rain stirrup would you be making it a new mob or just keep it as amethyst golem ?

[rain stirrup]

it's just the amethyst golem

[sly knot]

I am also going to do similar thing for BloodMagic Crystals so it would be nice if we share mechanics

[sly knot]

I see

[rain stirrup]

should be fine, but be forewarned that this does rely on some mixins for the amethyst golem

https://github.com/62832/ArsEnergistique/commit/272b46aa5a235e33f0a653a3b82ca9a5b5926db7

the actual conversion from block to budding block at least requires it, everything else such as harvesting just requires adding the relevant blocks and items to the shard, budding block and cluster tags

[sly knot]

I dont know how to read mixins

[rain stirrup]

(of which Ars for some reason uses its own instead of the Forge convention tags...)

[sly knot]

do you wanna upstream it or would it be easier to just create a custom mob ?

[rain stirrup]

the mixin really isn't that complicated but if you really don't want to do that you'd be better off making a custom mob

since there really isn't a way to "map" a block within a tag to a block from another tag for the conversion mechanic

if you want i can run you through it at some point

[sly knot]

Yeah works for me

[rain stirrup]

@distant lichen you think this is enough for a release? i'd just like to do a couple final spot checks and then basically get this out the door

right now i'm noticing that in 1.20 the Worn Notebook just displays a load of squares instead of actual letters

[sly knot]

1.20 is unstable right now

[rain stirrup]

yeah actually it seems as though this happens regardless of whether the add-on adds its own pages to the notebook

at least in dev envs, not sure about production

[sly knot]

you can get 1.19 out. 1.20 might be tricky since almost all addons are waiting

[rain stirrup]

i see

[distant lichen]

probably? I'm not really sure what other features this could have honestly

is the amethyst golem thing on 1.19 and 1.20?

also yea, like chonky said, most addons are waiting to release 1.20 versions on curseforge because ars might still make breaking changes

[rain stirrup]

yes, i added it to both versions

[distant lichen]

nice

... I just realized there should probably be a config file for all of these things...

[rain stirrup]

the only thing i can think of having a config for is the source to AE power conversion and potentially the max buffer of the output P2P tunnel

[distant lichen]

I was going to say those exact items lol

yea those would both make sense to be configurable

is it possible to make the capacity of the cells also configurable? as in, how much source is stored per byte?

that would be nice too

and finally the amount at which AE2 import / export buses move source

[rain stirrup]

it would be unorthodox but i suppose i can think about those two

[distant lichen]

I mean, more config never hurt anyone

players can just chose not to touch it

and there's a chance it helps some server owner

[rain stirrup]

i'll ask the AE2 guys whether the config for the amount of source per byte and operation would make sense

in either case i will add a config for the power conversion and buffer but i'll hold off on the actual keytype values (per byte/operation) for now

because i feel like making the getAmountPerOperation value configurable could side-step the need for acceleration cards altogether

[distant lichen]

... I'm not sure how that's a problem necessarily. If it's a server config that's up to the server owners, if someone in singleplayer choses to buff it, that's their choice

[rain stirrup]

i just don't see the point honestly

[distant lichen]

are we responsible for protecting players from themselves and making it too OP? Should we limit the max AE energy per source in the config to be waaay lower than it could be for that same reason?

yea I guess base AE2 doesn't seem to have those configs so we won't need them either

so yea the two you mentioned should be fine

[rain stirrup]

by the way, 20 AE per source is fucking ridiculous now that i think about it more closely

a more reasonable default would be 0.25 such that a full jar of source can generate 2500 AE

if it turns out in a large pack setting that the default should be higher then i'll adjust it accordingly

[distant lichen]

... have you seen how fast AE drains? that seems terrible

you'd force everyone to build a berry reactor to use AE2 at all

[rain stirrup]

10AE?

i suppose i'm overestimating how fast source can feasibly be produced

alright nevermind i'll just stick with 20

[distant lichen]

nah I probably had it too high

5 or 10 is probably good for the default

doesn't matter too much as long as you mention it's configurable in the project description on curseforge

IDK the exact numbers on AE2 energy but doesn't the lowest tier cell hold 200k?

so having a jar only give 2.5k seems... odd

you're saying 1 low tier cell = 80 source jars, and 1 high tier cell is like 8000 jars?

[rain stirrup]

lowest tier cell holds 1mil

which is 100 jars

highest tier cell is 25600

[distant lichen]

... I mean energy cells

not source cells

I think the lowest tier energy cell needing 80 source jars to fill would be a bit much

[rain stirrup]

ahh

yeah the smallest energy cell holds 200k AE

which by the current default of 10AE/source would be 2 jars' worth

[distant lichen]

I mean, 10 might still actually be a bit high

I always forget how small source jars are and how good tree / berry farms are at making source

not that it matters too much if it's configurable

but if anything we should make it on the lower end of reasonable

people are more likely to go to the configs and fix it if they notice it's too underpowered

than to do anything if it's OP by default

[rain stirrup]

let's say 2 AE per source then

10 jars to fill a regular energy cell and 80 jars for a dense cell

[distant lichen]

yea I don't see that ever being too high

nice

if you added the config for the output tunnel buffer that should be good

[rain stirrup]

alright, that's the config done

[distant lichen]

yay!

yea 1 blazing archwood tree is like a full jar... so needing 10 to fill the smallest cell does seem fairly reasonable

maybe closer to half a jar, still a lot though

I guess it's just hard to balance because usually RF per tick is limited by using expensive materials to upgrade generators

but source per tick is limited almost exclusively by your engineering skill and spellbook level

sourcelinks are super cheap

should I build a version and test it in a non-dev environment?
(only singleplayer though)

[rain stirrup]

sure thing

[rain stirrup]

if you could also take some screenshots to show off the features that'd be nice to have for CF and Modrinth pages

[distant lichen]

I'll try, I kinda suck at that though

it also needs a square logo

[rain stirrup]

they don't have to be works of art

[distant lichen]

and I have no idea what you can do there

[rain stirrup]

ahem
https://github.com/62832/MEGACells

[distant lichen]

what sort of background do you want?

[rain stirrup]

i guess some of the decorative blocks from Ars wouldn't be too bad

think i saw some nice-looking bricks before

[sly knot]

woah that github page is super cool

also why is the L like that lol

[rain stirrup]

it's from a wider font concept i played around with at one point in which each letter is formed from a 3x3 grid of squares

and the excess squares get retained as part of the letter so that each letter looks like a square tile overall

[sly knot]

did you make all those graphics and textures ?

[rain stirrup]

the screenshots were provided by other people who played around with it

the header images were done by myself and the textures were mostly adapted from AE2 itself

[sly knot]

they look amazing! You are insanely talented!

I love the colorscheme. I wish base AE2 had the same colors

[rain stirrup]

nah it's really nothing lol, but thank you

[sly knot]

honestly, do people use these super big disks ?

like 256M

[rain stirrup]

apparently they do

[sly knot]

do they have increased types or something?

[rain stirrup]

nah they're still at 63 types

i hang out on the All The Mods discord a lot and a lot of people who play their packs make use of them

[sly knot]

holy

[rain stirrup]

the M cells aren't anything that special, i'm more proud of the work i did for the bulk storage cell and the extra mechanics that that one offers

[sly knot]

bulk storage is single type right ?

[rain stirrup]

infinite single-type, yes

[sly knot]

Bulk Compression: Automatic conversion between ingots, nuggets and blocks for bulk item cell storage, with full support for auto-crafting via the Decompression Module
oh this is super neat

[rain stirrup]

and i do mean basically infinite for all practical intents and purposes considering the datatype used for the quantity

[sly knot]

what type ?

[rain stirrup]

BigInteger

[sly knot]

2^2147483647

damn thats big

[distant lichen]

um, I can't build the project

Step 'prettier-format' found problem in 'src\main\resources\arseng.mixins.json':
Can't automatically determine npm executable and none was specifically supplied!

I have no idea how to fix this and I didn't find anything related to gradle when I tried googling it

[rain stirrup]

ah, you need to have npm installed on your machine

[sly knot]

npm wot

[rain stirrup]

nodejs package manager

[sly knot]

yeah Ik

but why lol

[rain stirrup]

i use Spotless for code formatting and have Prettier enabled for JSON files

[rain stirrup]

just comment out the json block under spotless {} for the time being

[distant lichen]

ok

[distant lichen]

what file is this in?

wait found it

[distant lichen]

hmm, have you built and run it succesfully yet?

[rain stirrup]

haven't done so yet, lemme give it a go

1.19?

[distant lichen]

yea the amethyst golem mixin is failing

I've tried both old and the newest ars version

[rain stirrup]

ah, i forgot to disable remapping on that one i think

wait

[distant lichen]

on my end it looks like you did

what

[rain stirrup]

the fuck?

one moment

[distant lichen]

is the target on the at wrong?

no it looks right...

looking on the github for ars the method is still fine
https://github.com/baileyholl/Ars-Nouveau/blob/main/src/main/java/com/hollingsworth/arsnouveau/common/entity/goal/amethyst_golem/ConvertBuddingGoal.java#L58

but doesn't this set remap to false for all the inject annotations in the class?

@Mixin(value = ConvertBuddingGoal.class, remap = false)
public abstract class ConvertBuddingGoalMixin {

[rain stirrup]

yes it does

lemme try with remapping enabled, i have no idea why that would be required but

[distant lichen]

oh wait yea

it overrides a method from MC

[rain stirrup]

well no, that literally doesn't work since ars isn't using obfuscated mappings

[distant lichen]

no but it overrides an MC method

so I think you do need remapping ?

[rain stirrup]

ohhhh

[distant lichen]

I ran into somethign weird with remapping a few months ago

so that and the other method on canUse?

building and testing now

no luck

[rain stirrup]

hang on, i'm trying something out rn

well they're getting remapped now but it's still not fucking working for some reason

{
  "mappings": {
    "gripe/_90/arseng/mixin/ConvertBuddingGoalMixin": {
      "start": "Lcom/hollingsworth/arsnouveau/common/entity/goal/amethyst_golem/ConvertBuddingGoal;m_8056_()V",
      "canUse": "Lcom/hollingsworth/arsnouveau/common/entity/goal/amethyst_golem/ConvertBuddingGoal;m_8036_()Z"
    }
  },
  "data": {
    "searge": {
      "gripe/_90/arseng/mixin/ConvertBuddingGoalMixin": {
        "start": "Lcom/hollingsworth/arsnouveau/common/entity/goal/amethyst_golem/ConvertBuddingGoal;m_8056_()V",
        "canUse": "Lcom/hollingsworth/arsnouveau/common/entity/goal/amethyst_golem/ConvertBuddingGoal;m_8036_()Z"
      }
    }
  }
}

no refmap loaded?

[distant lichen]

do you have the refmap set up right in build.gradle?

it's not in the mixins json

I'll try adding it and test again

[rain stirrup]

oh fuck you're right

[distant lichen]

well, game launched

I'll test if it works right

but the game launched

do you wanna make and push the changes on your end?

[rain stirrup]

yeah i'm just trying to see if the changes i made just now work

okay yeah they don't

[distant lichen]

... what

how

I am very confused

it works on my end

I fixed the refmap and made them remap

and it works

non dev environemnt, game launched and he converted it

[rain stirrup]

yeah but i don't think you're supposed to manually add the refmap line to the mixins json

AIUI that's meant to be sorted out automatically by mixingradle

yeah nevermind i'm being a fucking idiot

[distant lichen]

... you're supposed to make the file manually so I fail to see why that would be the case

[rain stirrup]

the refmap file, no

but i suppose you are meant to declare it in the mixins json yourself

[distant lichen]

yes, the mixins json is created manually

so you need to specify the refmap manually

in the file

[rain stirrup]

yeah okay i see now

seems to be a ForgeGradle-only thing given that i've never had to do this for projects using Loom (Fabric/Architectury)

[distant lichen]

I imagine you'll also need to fix that on 1.20

[rain stirrup]

i will, yeah

[distant lichen]

wouldn't know because I only use forge

so do you wanna push the changes for both 1.19 and 1.20?

[rain stirrup]

yeah gimme a few

[distant lichen]

ok

[rain stirrup]

yeah there we go now

fucking ForgeGradle

also dk, check DMs for a moment

[distant lichen]

ok, building again to get some screenshots and test the other items

the file is still called 0.0.0 LOL

y'know what would be kinda funny?

a certus quartz skin for amethyst golems

[rain stirrup]

ooh

[distant lichen]

right click them with a crystal to change the model

right click with amethyst to change it back

IDK how hard that would be to do but it would be super cool

[rain stirrup]

that'll be for a future release for sure

also don't worry about the version number, i have a release workflow set up that'll pull the right version number from the tag of whatever release i make on github

[distant lichen]

oh that is cool

[distant lichen]

yea obv it would be dumb to delay the release for that

[rain stirrup]

https://github.com/62832/Fullblock-Energistics/actions/runs/5835127081

[distant lichen]

it's not super good but this is what I was able to get

shows all the most important features as far as I can tell

@rain stirrup so I have this basic screenshot, do you want me to get closeup screenshots of the operation of any particular machines?

or of the amethyst golems working on certus quartz I guess lol

[rain stirrup]

up to you

[distant lichen]

the aspect ratio on that screenshot also sucks let me try again

with the actuall friggin screenshot option this time

not sure if this is better or not

[rain stirrup]

too far away i think

would be better to get a couple closer shots of the individual mechanics

[distant lichen]

better angle

same setup or new build?

[rain stirrup]

same setup could be okay

[distant lichen]

wait wrong image

[rain stirrup]

was thinking closer but the way they're currently set up is way too spread out

i say let's leave the screenshots for another time

[distant lichen]

ok I'll do the rest some other day

it needs to be spread out enough to show the mana flying through the air is the problem

[rain stirrup]

yeah, fair enough

[distant lichen]

if they're too close together the screenshot is hard to take and even when you get it it's not as cool

[rain stirrup]

come to think of it i quite like this one

and this

[distant lichen]

ok, feel free to put those on the page instead

do you plan to publish it today?

[rain stirrup]

i'd say so

here's hoping i haven't fucked that release workflow up

[distant lichen]

I just had the stupidest idea ever

it would be very funny but is probably an incredibly dumb idea

an AE2 relay

think a cross between a source relay from Ars and an import / export bus from AE2

you can have it import or export like a bus (if using to export, needs a filteR)

it can take anything an export bus can

but at a distance from the network and send it to an actual interface

and it has particles with the AE2 blue-ish color instead of the ars purple one (the AE2 purple one would be too similar)

[rain stirrup]

sounds very ambitious

[distant lichen]

I don't think we should actually do it

there's no point

but it would be funny

I clearly enjoy relays too much

I added a potion relay to my other addon

exactly what you'd expect, it relays potions from jars

burst has same color as potion

[rain stirrup]

bury nice

alright, moment of truth

[distant lichen]

can you add at least 1 image showing all the stuff to the images tab? so it's not just full of P2P showcases

most users probably care least about P2P honestly, as cool as it is

I mean I say that, I actually have no idea

[distant lichen]

you building and uploading now?

first file on the project might take a while to get approved

[rain stirrup]

they'll get the idea for now i think

[distant lichen]

I guess it is simple enough

[rain stirrup]

i'll wait til later on to get some better screenshots from people playing with it in a proper world

also hop on Modrinth as well so i can add you as a project member

[distant lichen]

ok

done I think

[rain stirrup]

invited

[distant lichen]

accepted

[rain stirrup]

first file is up on curseforge

i fucked up my personal access token for Modrinth

[distant lichen]

um

why'd you upload 1.19.2 twice?

and are you sure you wanna upload 1.20 to curseforge?

you could post in it #1123778156386590770 and get it pinned I bet

[rain stirrup]

oh, right

[rain stirrup]

had to re-run the workflow

it'll get rejected anyways for being a duplicate

[rain stirrup]

yeah maybe it's not worth doing 1.20 just yet

[distant lichen]

I mean it's your choice but I'd recommend waiting a little longer

[rain stirrup]

i'll most likely set 1.19 as the master branch and just continue any dev shit there

[distant lichen]

for now does it make much difference?

also hypothetically if I did go crazy and spend a week implementing ME data relays would you add them? LOL

[rain stirrup]

no clue lmao

[distant lichen]

I just had a silly idea

a standalone AE2 addon that's just, like, magic stuff in general would be cool

[rain stirrup]

how would that work?

[distant lichen]

imagine an "energy storage cell" that can hold different types of energy from different mods

like, it has different types

like RF, source, mana (botania), etc

and works like a fluid cell but with those things instead

to make it feel more cohesive

[rain stirrup]

doesn't work that way considering all of those things use their own APIs altogether

[distant lichen]

yea, but like
is it really not possible to do all of them?

you could have some class handle the conditional loading stuff

you wouldn't need a single P2P tunnel since RF tunnels are already a thing so having everything be a separate P2P tunnel makes sense

storage is just numbers and import/export rules
I'm sure some monstrosity of an import rule could be made

not sure if it's a good idea

[rain stirrup]

it isn't

[distant lichen]

would be hilarious but yea it's waaay too complicated to make

[rain stirrup]

there is technically a "multi-capability" P2P tunnel implementation but it's exclusively a thing for the AE2 Mekanism add-on

and i don't imagine that would actually work well for caps meant for different APIs altogether

[distant lichen]

I don't consider addons to be canon

[rain stirrup]

well, it could, but it wouldn't be worth it

[distant lichen]

yea it's not a good idea

anyway with applied botanics being a thing, plus this, it would step on a lot of toes

[rain stirrup]

i'm not bothered about that in the slightest, it would just be a hassle to actually do

[distant lichen]

it would

it really would

do you know of any addons that add an RF cell?

I obv get why it's not in the base mod but it would be interesting

[rain stirrup]

no, but the guy developing AE2 Wireless Terminals has expressed an interest in making such an add-on

and i've also toyed around with the idea

[distant lichen]

oh nice

[distant lichen]

@rain stirrup since the ME relay is waaay out of scope of Energistique, would you be cool with me adding it in Industria and only loading it if Energistique is installed?

I'm planning to add an RF relay and move the potion relay from Omega to Industria so it would fit pretty well if I can make it work

(plus I have some ideas on using shared code for my 3 relay ideas to not do tons of extra work but still have splitter and warper and etc variants)

[distant lichen]

I had a really stupid idea for implementing the two way relay for ME networks

so there's a "relay node" part you can connect to networks

and the relay keeps track of the two networks it's connected to

and on each one it advertises itself as a storage
this storage wraps the other network's storage but when an item is inserted / extracted, it does it's visual burst and sends it to the other one

this is an incredibly stupid idea

but now I wanna see what happens if I do it

[distant lichen]

I'm going to go to programmer hell for this

[distant lichen]

my brain RN:
"let's take a storage mod designed to improve performance over using chest BS and kill the performance for literally no reason"

[sly knot]

what's an ME relay?

[distant lichen]

I just had the stuuupidest idea ever

imagine the source relay

but it's two-way and works for arbitrary items in an ME network

[sly knot]

so wireless ME ?

[distant lichen]

think a mix between an import bus, an export bus, a lag machine (because this is frigging stupid and probably will cause issues), a source relay, and a wireless AE2 network

I half got a prototype of one of the functionalities working and it already needs a major refactor cause it sucks so much

[distant lichen]

I don't say this for naught

well, it's not crashing, but right now it only works around 1% of the time when flushing the connection and 0% of the time otherwise

and again this is for a prototype of one of the functionalities

this is why this shouldn't be added for real

I just wanted items flying from an ME storage to a chest through a relay 😦

(👆: naive person)

[distant lichen]

now it stopped not connecting but it also stopped transfering items

from all my logging the simulate step is going fine but it just isn't calling extract in modulate mode and IDK why

I fully understand why this isn't a feature

huh I got it working

[distant lichen]

I'm going to programmer hell for this aren't I

now if I was serious with this project

what I'd do is make a new entity for the item moving around

that moved faster, moved in a straight line, and notified the relay when it arrived

then it could actually only be in 1 place at once (well 2 if you count the real item)

instead of using the ars one

but I'm not serious about it because I doubt this is a good idea in any way

if it ever turns out to be less problematic than I think I'll take another look

[rain stirrup]

i'm cool with that

[rain stirrup]

also we've just gotten approved on CF 😄
https://curseforge.com/minecraft/mc-mods/ars-energistique

@distant lichen

fucking pinged the wrong person just then

[distant lichen]

Oof

[distant lichen]

Yay!

[sly knot]

@rain stirrup I have an addon idea, not necessarily related to Ars but magic in general

would you be interested ?

[rain stirrup]

hm?

[sly knot]

I always wanted wireless ME to be a thing. Not the grid but cable connections. short range like 8-10 blocks

you think it is possible

[rain stirrup]

Ars Énergistique

[rain stirrup]

i think AE Additions already has something for that. Wireless Transceiver, was it?

[sly knot]

that is a bit overkill. I dont want anything long range or complicated

just want a cable replacement for small/early setups

for example when you dont want to drag a single cable to connect to 3 blocks that are 10 blocks away (also because single cable is not symmetric and can look ugly )

[rain stirrup]

hmmm

[distant lichen]

Isn't there also an immersive engineering AE2 crossover that adds super neat network cables in the style of IE wires? Lol

That would be my honest recommendation

[rain stirrup]

yeah i believe so, not sure if it's still around though

[distant lichen]

I thought I saw it earlier

[sly knot]

anyways you think this is a good idea/ even possible ?

[rain stirrup]

it can be done i believe, i just don't know if i see the benefit of it at short ranges like those

maybe i can think about it as an addition to MEGA some day

[distant lichen]

I imagine it's easier than the wireless thing I'm doing in any case

[sly knot]

I like magic and (my self made) magic laws state that cables are a no-no 😂

just curious, how complicated is ae2 API ?

[rain stirrup]

...50/50?

i couldn't give you a great estimate there

[distant lichen]

It's not that complicated it's just suuuuper tedious

90 might say otherwise but 90 is techbically using non API classes to do all the busywork

[rain stirrup]

you're never truly going to be able to stick to just the API if you're making something that relies on the base mod anyways

[sly knot]

thats pretty true

[distant lichen]

@rain stirrup the ars API keeps being mean to us

the prism you were asking about? the block itself needs to extend an interface

[rain stirrup]

yeah i was about to say LMFAO

[distant lichen]

so to make a P2P tunnel, yet another mixin

[rain stirrup]

the event is attached to a fucking block interface

[distant lichen]

of all things

I mean, maaaybe it's meant to be for performance?

there are a lot of spells flying around sometimes

but still, actually wild

luckily it's only 1 method you'd have to mixin so it's not too bad

just get capability on that side

[rain stirrup]

might as well turn it into another cap, yeah

[distant lichen]

and make a new spell prism capability I guess

[rain stirrup]

yeah it just has to be IPrismaticBlock

at least it's only one method needed to implement

[distant lichen]

note to self: if I ever make a standalone mod, make everything API related a capability so that it actually works with more than diddly squat

[rain stirrup]

Technici4n suggests that we ask for a general event instead of the current block event

so that would obviously not require a cap at all

[distant lichen]

oh like an event when the spell projectile hits something?

[rain stirrup]

yes

[distant lichen]

that makes more sense

we should ask Bailey about making PRs on 1.20 for this kind of stuff

[rain stirrup]

for sure

[distant lichen]

make prisms use an event instead of hardcoding the check for inheritance

and make source a cap instead of interface on the BE itself

those are the only two things I think

[rain stirrup]

just about, yeah

[distant lichen]

and they will need to be separate PRs

I really should probably help with them

but I also kinda don't feel like it because I already have to make a PR myself

[rain stirrup]

problem is i'm not particularly good at event stuff in Java

the cap PR i'd be more than happy to do myself

[distant lichen]

doesn't forge use it's own event system? or at least something similar

yea def if you can do the cap PR

event seems trivial I can do that

the capability is in sooo many places though

I couldn't possibly find the motivation

making PRs is slow and boring

and I'm always scared of losing my effort if it gets rejected

so I overabuse mixins, its a problem

... ok so this PR plus two others I need to make... means I need to find the motivation to make 3 separate PRs

[rain stirrup]

also i had to make another release for arseng because apparently i forgot to tweak the texture path for the source renderer in ME terminals

beta.1 would just have a missing texture for source stored in ME because 1.19 Ars's block textures are under textures/blocks and 1.20's are under textures/block

ebin

[distant lichen]

oh lol

oof

[rain stirrup]

i'm just not going to bother with any further commits on the 1.20 branch until Ars fully moves over to 1.20 and then i'll port the 1.19 branch all over again

but honestly now that i think about it that spell P2P tunnel would be a really neat feature

[distant lichen]

that does seem easiest, doing 2 workspaces at once is pain

though if you were planning to actually play your addon absolutely don't feel bad about supporting whatever version you want

(personally I wanted to use this addon which is why I'm trying to help with it)

but we should actually prioritize the Ars PRs over everythign else

because IDK when Ars will stop accepting breaking changes so that addons can port

but it's probably soon and I really don't want to wait for 1.21

[rain stirrup]

true, i'll put the spell P2P tunnel on hold for now until that gets sorted

[distant lichen]

so to confirm you're doing the cap and I'm doing the projectile event?

[rain stirrup]

yes

the only thing i'd need to clarify is if i should be PRing exactly what you've provided with things like the extended interface and wrapper cap

[distant lichen]

no extended interface I think

if a new method is needed add it to the original interface

use the original interface for the capability

[rain stirrup]

yeah that's what i meant

[distant lichen]

I think at least the one for whether relays can take source is necessary

and would need to be there on the relay

actually IDK if you wanna change the relay direction thing to support multiple directions

since right now if it's diagonal it can act really weird and it feels kinda sucky

[rain stirrup]

how do you mean?

[distant lichen]

if the relay is diagonal to a thing with the cap it only searches one side for the cap

which sometimes misses it depending how it's oriented

or the other option is to make the dominion wand support directions

that would be nice in general

dominion wand change would be great
it makes an already invasive API change request even more extreme

wait no hold on

you could do a bunch of deprecation lol

keep and deprecate the old wand methods, add new ones that keep directions and have a default of just calling the non direction version, and save the direction on the wand

[rain stirrup]

not sure how confident i'd be to do so on a code base i have very little experience with but i'll see what i can do

[distant lichen]

well I say a bunch

if you only do it for the wand it's 2 changes

oh also since right now the AbstractSourceMachine is API for some reason

you could make it give the capability by returning itself

[rain stirrup]

what i might be able to do as well is add you as a collaborator on my forked repo to make sure i have another set of eyes on what i'm doing

[distant lichen]

thus making it less likely to break any addons

[distant lichen]

that sounds great actually

[rain stirrup]

i'll just copy every branch for now since i'm not sure which branches we'll end up making a PR to

is there ever a chance that we'll have these backported to 1.19?

[distant lichen]

heck no 1.19 is on the bugfix only stage

[rain stirrup]

right

[distant lichen]

speaking of which I should make my 1.19 bugfix PR before helping with the API related ones on 1.20

[rain stirrup]

i should have just copied 1.20 only then

[distant lichen]

so I can be doen with 1.19 as far as PRs go

[rain stirrup]

alright, you take care of that then and let me know when you're ready to sort these ones out for 1.20

for now i'm gonna keep trying to see if ArsEng can make it into an ATM pack for wider testing :^)

[distant lichen]

LOL

[rain stirrup]

hey i already have at least a bit of clout there thanks to MEGA

[distant lichen]

makes sense

I hate workspace setup

[rain stirrup]

you using an SSD for your projects?

[distant lichen]

yea

certainly helps but still annoying

[distant lichen]

ok made my 1.19 pr, moving onto 1.20 now for the big ones

[rain stirrup]

sicksicksick

you wanna work on the cap one together first?

[distant lichen]

oh

um, sure

I was working on an old one that I needed to fix before trying to PR again

but I can do the cap one

have you made any changes yet? and if so can you push them?

@rain stirrup

[rain stirrup]

no, not yet

for whatever reason my project refuses to build properly since it can't download Placebo

are you using the 1.20 branch of Ars as well?

i'll let you finish with yours while i sort this shit out

[distant lichen]

I am on the 1.20 branch

ok I'll finish mine up

it's basically moving all the logic in my old PR to an interface and deleting everythign unrelated ot the interface

so it's actually proper API stuff

[rain stirrup]

okay i see, progwml maven is down

now it's building

also you wanna voice again for this one, i wanna try out that one "Code With Me" IDEA feature for this

[distant lichen]

I have no idea how that works lol

[rain stirrup]

real-time collaborative editing supposedly

[distant lichen]

I imagine you can explain on voice call lol

[rain stirrup]

yh sure

[languid remnant]

It's so interesting going into this channel and reading about how this addon is progressing

Even though I have no idea at all what is being said

[distant lichen]

basically it's me being overly eager to have it released and mostly breaking things but occasionally getting some actual work done

that's the 5 second summary

[rain stirrup]

also me sperging out over code style

[distant lichen]

And that

[rain stirrup]

but anyways, i am still intrigued by the idea of the spell P2P tunnel but don't know whether to start working on it just yet

i assume that general event PR we spoke about just isn't going to make its way to 1.19, is it?

[distant lichen]

I mean

it's technically possible as it's a non breaking change

but I wouldn't hold my breath

[rain stirrup]

true, could simply deprecate IPrismaticBlock then

[distant lichen]

we could

IDK how that works though, would we need to make 2 PRs or say on the PR that it needs to be ported to 1.20 or what?

I don't do this very often as you can tell

[rain stirrup]

no idea

i think we should have asked Bailey first on the matter

oop! #api-development message

[distant lichen]

you got an answer so fast lol

[rain stirrup]

@distant lichen i think something you did previously with the cap broke the imbuement chamber with interfaces

looks like the whole relayCanTake thing you added with the interface brought back the need to blacklist certain block entity classes such as ImbuementTile

this fixes it for now

also got another situation but i think this might have been my fault for trying to invalidate a kind of cap that isn't typically invalidated properly by AE2 anyways
https://github.com/62832/ArsEnergistique/issues/3

[rain stirrup]

wait i'm an idiot the crash log isn't even about the interface but the source acceptor

what did they mean by this

[rain stirrup]

also, for the whole API cap PR we should consider defaulting some of the methods we added

[distant lichen]

Oops

[distant lichen]

erm

sorry, can you explain how that fixes the issue?

[rain stirrup]

i genuinely couldn't tell you but it does

[distant lichen]

or really what the issue was in the first place

[rain stirrup]

otherwise when using interfaces the imbuement chamber takes in all 200 source for a gem but gets stuck at 40% like before

[distant lichen]

what's the actual issue here?

[rain stirrup]

because it tries drawing source from itself, i think

[distant lichen]

... oh yea that's why we neeeded two can take functions

[rain stirrup]

somehow it didn't do so with regular jars which was interesting

right, so we did already account for this in the API PR then

[rain stirrup]

speaking of which we should probably default the machine-specific methods to return the result of their respective general method

and just override them as needed in any of the specific BE classes

otherwise it's too much clutter needing to override each and every method when implementing the interface

[distant lichen]

no, we shouldn't because AbstractSourceMachine does that already

you only need to implement everything if you're not extending that at which point it probably makes sense anyway

which is parity with how base ars does it

base ars has no defaults in ISourceMachine but they're all overridden on AbstractSourceMachine

[rain stirrup]

that doesn't mean there shouldn't be defaults at all for things that don't override AbstractSourceMachine

[distant lichen]

I thought it was best to do the same thing, is it not?

[rain stirrup]

which in the case of this add-on is going to be... all the time

hm

i mean, most of the time when the general method is true then so is the specific one, right?

so does it not make sense to default the specific?

unless i'm wrong on the first question

[distant lichen]

I have no idea

I just tried to make the PR work the way it does in ars

and gradle keeps giving me new issues each day so I can't really test at the moment

[rain stirrup]

i mentioned there was a problem with one of the maven repos in DMs, it seems progwml is down

so remove that repo for the time being and it should work

[distant lichen]

I guess I had another internet hickup, it was telling me it couldn't find forge lol

[rain stirrup]

ah

[distant lichen]

😐 my internet is just really slow today apparently everything I try fails like half the time

including sending messages on discord LOL

[rain stirrup]

restart your router?

[distant lichen]

oh might be a good idea

[rain stirrup]

@distant lichen sourcelinks are only supposed to send source to source jars, correct?

if so, then this along with an override on SourceJarTile to return true should be reasonable

[distant lichen]

.... but no because Ars doesn't add default values in the interface, does it?

I'd say make the override in abstract source machine return false

[rain stirrup]

what bearing does that have on whether we should include defaults

[distant lichen]

sure we can include them

[rain stirrup]

if there's hardly any reason to override it for anything that isn't a source jar then it might as well be default

also as it stands machinesCanTakeSource seems a bit redundant

since every implementation and override of it is the exact same as the implementation/override for canProvideSource

[distant lichen]

and thats' literally what we need to fix the imbuement chamber

[rain stirrup]

isn't the imbuement chamber already fixed by the false return on AbstractSourceMachine::canProvideSource?

[distant lichen]

it would be yea

that would also stop relays trying to take from it which they could do before

do we just wanna assume that was a bug?

[rain stirrup]

i can't see any good reason why a relay should take source from an imbuement chamber, so it might as well have been a bug

in that case if it's alright with you i'll rip out machinesCanTakeSource since it's entirely a repeat of canProvideSource

[distant lichen]

but aren't sourcelinks meant to return false on it?

literally only the source jar is meant to return true there

but canProvideSource needs to return true on sourcelinks as well

[rain stirrup]

they already do from AbstractSourceMachine

...hang on

[distant lichen]

do they not return true for canProvideSource?

[rain stirrup]

you never added that override from what i'm seeing

but yes, now that you are mentioning it again i see what you mean

[distant lichen]

well that's an implementation mistake

doesn't mean we need to delete methods on the interface

[rain stirrup]

in that case the default for machinesCanTakeSource shall be return canProvideSource() and the overrides on SourcelinkTile will be false and true respectively for those

also i'm going to add some javadoc to these methods since it's going to be very fucking confusing otherwise

also it might help adding a default to canProvideSource just so that this isn't actually a breaking change for other add-ons if this gets backported to 1.19

maybe not though

[distant lichen]

I mean, I guess that would make sense

are you making defaults for the other two?

that said I don't see this ever getting backported

[rain stirrup]

those are already there yeah

it's just canProvideSource that i'm debating now

also, could you remind me again what the thing was with directionality that made you adapt the relays to work with both position and direction? that still seems a bit half-baked to me

[distant lichen]

they just save the direction on the block that the wand was used on

so you specify where to insert / extract when you link it

what's half baked about that? woudl you rather it do hacky math that's wrong on the diagonals?

[rain stirrup]

honestly i'd just solve it by having another relay pointing directly to the face i want to send to or receive from

i think this is just making a problem where there isn't that much of one

[distant lichen]

what problem is it making exactly?

[distant lichen]

that becomes annoying quickly but fair enough I guess

[rain stirrup]

like why would you really want to be able to have a relay fire through a block only to hit the back face of it

makes even less sense at that point than just picking out the closest face

besides you're not accounting for the direction in anything like ParticleUtil or the on-screen text for the dominion wand so it's basically a change no one will see except in code that looks somewhat messier now

honestly i think the direction thing is at the very least rather out of scope for this current PR

[distant lichen]

how is that out of scope

that's literally how capabilities work

the wand already saved directions too so I didn't even change that

[rain stirrup]

issue is, the direction saved on the wand doesn't end up used anywhere

there's the getFace method within DominionData and following that along leads to a complete dead end

so what are we even using here for the cap stuff

never mind, i'm fucking dense

i see the overrides for those methods on RelayTile

though you did forget to pass that direction into getCapability in RelayTile

[distant lichen]

I did?

what did I do then lol

[rain stirrup]

you just passed the cap on its own

so you called the method that overloads with a null direction

you can check my commits on the forked repo if you want

[distant lichen]

ok I'll check out the changes you've made

I never even tested this yesterday, did I?

lol

[rain stirrup]

¯_(ツ)_/¯

[distant lichen]

well I'm testing and so far it all works as expected

[rain stirrup]

i suppose all i should really do is just not use Pairs and instead have separate fields for position and direction

because it's just really unnecessary boxing and unboxing at that point

[distant lichen]

I guess yea

you'd need to change the functions too

the current ones should return block pos and make new ones for direction

are you sure you don't wanna make the PR yourself? you've done most of it and you're the one who needs it most

[rain stirrup]

i suppose i can do it

[distant lichen]

... not looking forward to switching the workspace back to 1.19 to make the spell projectile event PR

we need that twice, right? 1.20 and 1.19?

[rain stirrup]

it would be nice but don't feel too pressured to do it on both

[distant lichen]

but if I don't do it on 1.19 we can't make a spell P2P tunnel

until 1.20

actually wait

how the heck would a spell tunnel work?

you can't split up a spell between outputs

how would a spell P2P tunnel send spells if there's more than one output? chose one at random?

should it only send projectiles, or should it make the spell resolve somewhere else if you use touch?

[rain stirrup]

yeah, at random was the suggestion from Technici4n

[distant lichen]

the other option is round robin

what does the item P2P tunnel do?

[rain stirrup]

good question, i haven't used that one before

and it'll be a while before i can since i have to go sleep soon

[distant lichen]

oh yea true

[rain stirrup]

probably just projectiles

[distant lichen]

any particular reason why?

[rain stirrup]

i don't know how it would work to support touch spells against the input P2P

and it's probably not that useful to make that work

[distant lichen]

@rain stirrup you know what would be nice? if we could somehow make the bookwyrm not totally obsolete

maybe a variant of the storage lectern that makes it act like an interface for a network

so that you can at least have the cute mob still

[rain stirrup]

ME Storage Lectern...

[distant lichen]

Yes exactly

Would you be willing to add that to the mod if I got some version of it working?

[rain stirrup]

sounds good

i should probably be adding you as a collaborator to the repo

ideally though i'd want to prioritise the spell P2P when that event gets backported

[distant lichen]

Yea me too

But I also feel bad for the bookwyrm

[rain stirrup]

could you give me a quick rundown of what the bookwyrm and the storage lectern do generally?

[distant lichen]

Well

Normally the storage lectern is one of those storage things

You link it to a bunch of chests

And you interface with it like a crafting terminal

And visually the bookwyrm moves items to and from the chests

[rain stirrup]

i see

[distant lichen]

@rain stirrup I'm not sure the conversion speed of certus quartz blocks into budding variant is right

I was using them in a survival world and it's like 20x faster than they converted budding amethyst

might also just be me being dumb, wil need to test more

nope, after further testing they are the same. sorry.

[rain stirrup]

all good

[distant lichen]

later this week I'll see if I can do anything bookwyrm related

[rain stirrup]

no rush

i would like to see about backporting that spell event though

[distant lichen]

Oh yes I'll do that ASAP since it's PR related

Then I'll work on my mods for a bit I think

While I brainstorm possible ways to make the bookwyrm involved

No point coding it if IDK what the feature is for sure

Oh once the spell event makes it to an update I'll do the spell tunnel as fast as possible

There also might be a crash with hoppers I need to look into

[sly knot]

can you guys pin the repo/curse page here ?

[rain stirrup]

will do after this

@distant lichen

this is coming from someone using Xacris source berry reactors

anyway

https://github.com/62832/ArsEnergistique

[rain stirrup]

https://www.curseforge.com/minecraft/mc-mods/ars-energistique
https://modrinth.com/mod/ars-energistique

[rain stirrup]

There is stackable and there is 25000 jars in a single cell
I think you could divide that by ten and still be ok.

if you don't have any objections then come 1.20 i'm changing the capacity to one jar for the 1k and 256 jars for 256k

and any higher than that can be MEGA integration (up to 262144 jars)

only reason i'm not doing this now is because i don't want to touch my MEGA 1.19 branch except for bugfixes

[distant lichen]

Huh

[distant lichen]

.... ONE jar? It'll be unusable!!!

I've been playing ars super casually and Ive generated like 12 source jars passively

Imagine once I set up a generator to automate stuff

I definitely object to that

[rain stirrup]

ten?

we're only talking about a fucking 1k here

literally the lowest tier cell

[distant lichen]

I mean, true

But like, you still make source very fast

[sly knot]

not really. my entire ATM 7 to the sky inv was in 8 1k disks

so it should be somewhat equivalent to normal item capacity

[distant lichen]

In which case if the 1k is under 25 jars it's literally useless

[sly knot]

no that would be too much

I would say 4 would be a good amount

[distant lichen]

Recall full jars can be put in an item cell

And they stack so they don't use up types or anything

[distant lichen]

How

What

[rain stirrup]

yes but how long does it take to get that many full jars to stack in the first place

[distant lichen]

To fill an item cell? A while

[sly knot]

source gen infinitely scalable so dont compare that way

[distant lichen]

To fill the proposed 1k cell? Literally just slap an agronomic sourcelink on your food farm and it'll fill itself in a few days

(unless you use beef or something, I'm using bread)

[sly knot]

1 disk drive can would be able to store 32 jars in a single block if we go 4 in 1k disks minimum which is a good number imo

[distant lichen]

???

[rain stirrup]

40*

[distant lichen]

So is item and fluid gen

[rain stirrup]

at 10 cells per ME drive, 4 jars per cell

[sly knot]

ah yes

[distant lichen]

Ah

[sly knot]

that still is fine

[distant lichen]

What we've learned today is that it needs to be configurable

[sly knot]

I dont think so

[rain stirrup]

i'm not making it configurable

[distant lichen]

Bruh

[sly knot]

base Ars Nouveau doesnt need alot of source. if you still need more source, you can craft better disks no?

[distant lichen]

Think of it this way

All the source usage numbers in ars are configurable so the cell capacity should be too

[rain stirrup]

...no?

you can't configure the capacity of Ars's own source jar, can you?

this doesn't follow

[distant lichen]

Think of it this way V2

You shouldn't accidentally fill up 1k cells from a passive farm made in 5 mins with leftover resources from your first mining trip

[distant lichen]

True, you can't

[sly knot]

why not

its 1k

[rain stirrup]

people accidentally fill up regular item and fluid cells all the time

[sly knot]

its cheapest disk you can make

[distant lichen]

Because source farms get a lot better

[distant lichen]

From that kind of farm though?

Oh well

[rain stirrup]

think of it this way
assuming 1k did hold a single jar's worth and 256k held 256 jars, how many jars would a full drive of 256ks hold?

2560 in the space of a single block where an actual jar would have been

[sly knot]

please dont make it single jar. atleast make it 2

[rain stirrup]

i'll make it two, fine

[sly knot]

yeah!

[distant lichen]

If it's under 4 I'm out

[rain stirrup]

and then 4k becomes 16 jars and 16k becomes 64

[sly knot]

bruh. 1k disks are super cheap to craft.

[rain stirrup]

you overestimate the power that a 1K is supposed to have

[distant lichen]

Source is super cheap to make, your point?

[rain stirrup]

FUCKING WATER IS INFINITE

how much water do you think a 1k fluid cell can hold

[sly knot]

lol where is the chat going

[distant lichen]

This that started the conversation is a 256k jar

[distant lichen]

More than a FUCKING CAULDRON I thought

[distant lichen]

I also don't get your problem with this

Like, even if we accept it's your job to protect players from themselves (which you can have if you want)

It's never your job to protect modpack makers from themselves beyond not allowing crashes and such

[rain stirrup]

ask on the AE2 dev channel about making it configurable and see what they respond with because i'm not sure at this point

but i doubt they'll see the point either

[sly knot]

making it configurable will break the entire type system

atleast for items

the " total bytes" wont match if it was configurable

[distant lichen]

Not making the bytes configurable but the source per byte lol

[sly knot]

okay 90 how about this

[rain stirrup]

if you can't configure the items per byte from 8 or fluid mB per byte from 8000 then i don't see why source should be configurable

[distant lichen]

I would also like to point out that people constantly complain about how small the storage of a jar is, it really isn't much of a metric to measure by

[sly knot]

you use 3 jars to make 1 1k disk like how you combine 3 1k disks to make 1 4k disk and each 1k disk has 4 jar capacity. What about this ?

[distant lichen]

"if other people are hostile to modpack makers I'm obligated by honor go be as well! Scram, modpack makers! "

[rain stirrup]

how is that hostile to modpack makers

[distant lichen]

I already went down from 25 to 4 which is over 5x less

Chonky agrees 4 makes sense lol

You can go up to 4

[sly knot]

I am fine with either 2 or 4

[rain stirrup]

i'm going to make it 5 in that case because having 1k be 4 and 4k be 16 and so on makes no sense

[sly knot]

how so ? Isnt that how rest ae2 works?

[distant lichen]

I mean, it doesn't make no sense but I see what you mean

5 sounds reasonable

[rain stirrup]

1k is 1024 bytes, 4k is 4096

not 4096 for 1k and 16384 for 4k

[sly knot]

I dont get it

[distant lichen]

Congrats, now a 256k cell can store half as much source as a 1k item cell

[rain stirrup]

jesus christ

[distant lichen]

What

It's true

[sly knot]

bruh you are not looking the disk cost

you know how expensive it is to craft 256k disk ?

[distant lichen]

Exactly my point

It stores LESS source than the 1k item cell

Why would anyone use source cells for bulk storage

Which is the point of cells

[sly knot]

oh my bad I read it wrong

[distant lichen]

I mean, these numbers are certainly usable

[rain stirrup]

applied botanics doesn't do any of this shit with "uhhh but imagine if you could fill mana pools as an item AND stack them!!!"

[sly knot]

I dont think that is the point of the mod is it

[distant lichen]

Because you can't

[sly knot]

its not for mass storage but having everything in ae2

[rain stirrup]

why can you for Ars anyways

[distant lichen]

Do you have any idea how much MORE value one pool of mana is than having 1 jar of source

It's a HUGE difference like holy cow

If you use the same numbers for both you're beyond bad at this

Imagine a 1k cell with 5 mana pools good god thats very high

Versus it's not that many source jars

[sly knot]

90, you will probably make the correct decision given all your experience with ae2. I will leave this discussion lol. getting too heated for me :P

[distant lichen]

In my opinion 1 mana pool is worth at least 10 source jars though figuring out specifics is hard

[distant lichen]

Sorry about that.
Bye

[rain stirrup]

then have your 10 source jars per 1k and i'll leave it at that

because right now my priority is to figure out why the fuck i introduced a memory leak to MEGA Cells

i didn't want to be spending this time so far yelling over shit

[distant lichen]

How much is it in the mod ATM? 1000?

That'll be very noticeable already

We should at least see what the results of that are before going any lower

[rain stirrup]

the results of it are going to be that no one bothers to craft the 256k and they instead stick with only the 1k

i'm calling it

[distant lichen]

That's because nobody bothers do cool stuff with ars

Id bet people that don't build huge item farms never make 256k item cells either

I'm calling that

[rain stirrup]

they absolutely do

[distant lichen]

Really

What the heck do they use them on

[rain stirrup]

you're supposed to be using large-capacity cells for bulk storage of what you have a large amount of and smaller stuff for things that only take up types

have you SEEN how much shit like iron you can get in a kitchen sink pack like ATM

[distant lichen]

...

Huh

So what I'm hearing is people are really not using ars enough if the packs make all sorts of item automation that easy

Im assuming me using the 256k cell doesn't count?

[rain stirrup]

as it stands? probably