#desktop neurons
1 messages ยท Page 4 of 1
I think I'm gonna go sleep.
just discovered that some of the javascript in the xmls doesn't work because it refers to nonexistent fields
discovered it because a neuroling was doing the PullUpShimeji action on the top of a window which it should not be able to do
i am going to be extra safe when rewriting this javascript stuff by always using the getters instead of directly accessing the fields because that will allow for more flexibility if we need to change how things are accessed
Are you rewriting the scripts?
Because you don't need to use the getters
Part of the nashorn compatibility mode features is that it tries to access the getters first, before trying to access the fields directly
Which it can't, anyway, cause those fields are private
i am using nashorn right now
and i know i don't need to use the getters
but using them will allow potentially changing how those things are gotten in the future
It will automatically use the getters
They can't access the fields directly
Access controls
And trying to change it would break any old shimejis
Oh, so it sees "mascot.environment" and it automatically does "mascot.getEnvironment()"?
Read this part here
That describes nashorn compatibility mode, which is meant to mimic nashorn, so it's the same with nashorn
oh i am not changing the way the script engine works right now
i'm just changing the xmls
I know, but you don't have to
eh fair
Even if you keep the script as it is, where it looks like it's accessing the fields, it's actually using the getters
though for some i do need to change them since the wrong properties entirely are being read
That was one of my biggest headaches
one of them is supposed to be checking whether a mascot is on the work area floor but it instead checks whether it is on any floor
so i'm going to go through and correct all of those mistakes
I didn't realize it did it, so I was trying to make proxy objects and use reflection to bypass access controls for only the scripts
That link I sent shows how it chooses which getter to use
If it doesn't follow those rules, the xml's doing it wrong
no the xml does it right
Otherwise, I would keep it the same, unless we don't care about backwards-compatibility
it accesses existing fields properly; it just sometimes accesses the wrong ones given the context of what it wants to do
Can I get an example?
here's an example of a Condition block in the default behaviors.xml file
i included the behaviors for later reference, but right now we'll just be talking about the condition itself
it wants to check whether the mascot is currently standing on the work area floor
What do you mean by it choosing any floor?
so it checks mascot.environment.floor.isOn(mascot.anchor)
I ran into this bit when I was working on it.
but that is wrong, and checks whether the mascot is on any floor
instead, it should be mascot.environment.workArea.bottomBorder.isOn(mascot.anchor)
yes i know
i keep saying this
it's not getting a nonexistent field
it's getting the wrong field given the context of what it wants to do
What should it be getting
i just said it 
note the upper portion
that gets the top of the active window
the condition is supposed to be met if and only if the mascot is on the work area floor
otherwise, if they start the PullUpShimeji action on a window and the window is moved, they just hover in place
i experienced that firsthand and that's how i discovered the issue
PullUpShimeji is in this Condition block, by the way.
Right at the bottom.
I assume that getFloor() used to only return the work area floor, but it was changed and the person who did that forgot to change the XMLs.
Not really
That would explain stuff like this. The second line here is redundant.
what do you mean by this 
Give me a sec. I'm just double checking to see if I know what some of these classes represent
the work area represents the screen minus the taskbar
on windows, at least
"IE" is used a lot throughout the code and XMLs to refer to windows
My guess is that is checking if it's on the floor of the current area, or the top of the area, whether a window or the bottom of another screen
not the operating system windows; the window windows
yes, it's checking whether the mascot is on the floor of the work area or on the top of the active window
so the xml for checking the work area floor is using the wrong code because it's also checking whether the mascot is on a window
These animations should also work on top of windows, right?
Or, behaviors, rather
that is not intended behavior
they are supposed to only do those behaviors when they are on the work area floor
hence the comment right above it saying "On Work Area Floor" 
Not here?
yes, not there
the behaviors to be done on any floor go under the "On the Floor" section
just changed that condition, by the way
was previously that
And what are you changing the work area floor to?
as mentioned earlier
hm, i'm also noticing that some javascript in the xmls uses #{code here} and some uses ${code here}
is there a difference
There is a difference in the parsing, but I don't know what it actually does, cause I haven't looked into it
Oh, wait
It's right there
Does it reevaluate every frame, I would imagine
Yeah, it caches the result after execution
i would imagine it clears it from memory after the next frame if set to true, or something
i see 
so $ caches it and # does not
so $ should be used for things which are constant
Constant meaning during the lifetime of the current behavior, I believe
It would reset once it switches
actually
yeah that makes sense
because the things in the XMLs which use $ also use Math.random()
The scripts are built and compiled everytime a behavior is started
so it would be preferable that they keep the same value throughout the behavior
er, desirable, rather
that seems like the more common word used in this context
Btw, did you see the pull request?
yes i responded
Oh, just saw
Regarding that stuff, yeah, I'd need you to at least clean up the Maven build stuff
now seems like a good time to mention that i already switched to maven myself because i didn't agree with the maven shading stuff
also used the nashorn maven artifact as a temporary fix to allow java 21
temporary because i have found a source which suggests that graalvm javascript is faster than nashorn when used correctly
https://github.com/oracle/graal/issues/3109#issuecomment-801855782
here's the source
the thing is, you are using the GraalJSScriptEngine in your code, which, according to this, only exists for legacy support and is not as fast as using Context directly
I mean, yeah. I have seen a few claims like that, and I would believe it. Graal itself may be faster than the standard JVM due to a lot of their JIT compiling stuff
i mean, this claim comes directly from someone who works on graal
so i'd definitely believe it
If you look at my commit, they aren't mutually exclusive
I use Context in the GraalJSScriptEngine
yes, i notice that you use Context
Well, I guess let me look
but that's the thing
GraalJSScriptEngine is just a wrapper for Context from what i can gather here
it exists only to integrate with the existing Java scripting API
but it's faster to use Context directly instead of using the script engine
They are doing something different
I'm looking at the code
They are accessing the graal engine through the Java ScriptEngineManager. This isn't using a context at all
not on the surface, at least
maybe it's creating a default context in the library itself, i dunno
What they mention here is that they are casting that ScriptEngine to a GraalJSScriptEngine, although it wasn't constructed as such
Then they take the polyglot context from that
I'm creating a GraalJSScriptEngine with a polyglot context from the start
Which, I believe, means that it's fully migrated to the Context API
Wouldn't this be fully migrating to Context, though?
That's worse than what I'm doing
Because I'm using the engine, I can precompile the scripts before running them
As they don't change after the Script object is initialized, the compilation will save a lot of time
ah, i see
I'm looking through the source for it
It's calling the polyglot context in the background for the eval
Anyway, Graal should be faster for the scripts. I'm not sure if they're actually that resource intensive, though
If it's used for runtime execution, I think it'd be faster in general, cause it'd be using some interesting JIT compilation stuff
And I'm actually pretty interested in using it to generate native images
It would be more performant and not rely on the user installing a JVM, if we wanted to go that direction
i suppose so, but i don't want to make changes that big; plus, it's supposed to be cross-compatible and having multiple native executables for each platform instead of one which can run on most platforms might complicate releases, because the Ant script generates three zip files (one for each of the default behavior XMLs) so we would have to generate three zip files for each native executable on each release
i mean, i guess we don't have to since we don't release in that fashion, but i'm thinking generally
I mean, the process for generating them is just throwing a jar at the Graal compiler, given you have done a little configuration
That's the reason I was trying to shade the jar
The compiler needs it to make a standalone executable
my point being it's a lot of files in the end
right now, the program supports windows, may or may not support mac, and has very shitty linux support
that would be 9 zip files

be fair though
electron is much more professional, important, and heavily used than shimeji
tbh, I don't know what the three default behaviors are for
Also, I don't know what that changes for this
mischievous allows all behaviors, professional has some behaviors set to never happen, and calm has even more set to never happen
I mean, couldn't we just add a setting for that?
I mean a setting to switch between the xml files
that would require that everyone has three xml files
Where are they?
in the conf directory
Or, the one in each release
the ones in each release are renamed to behavior.xml
The schema?
and the other behavior files are all removed
these three
for each zip file, one of these is kept, and the others are removed
the original behaviors.xml here is also removed
and then the remaining behavior xml is renamed to behaviors.xml and takes its place
no i haven't finished fixing the xmls yet and i don't want anyone potentially using this before that because rhefajvdkanveur
that was stream of consciousness
Or at least a pic of the conf dir?
Of one of the ZIPs?
ogey
hang on i'm having trouble building it
<-- fairly experienced programmer
I guess I don't understand why this would be an issue
it would be a hassle for everyone to have to make three variants of their behavior files
would also be a hassle to change a single thing about the behaviors because it would need to be done thrice
Wait, who uses the behaviors?
... The mascots?
And these default behaviors are for the shimeji creators?
they're used in releases for shimeji and are by default only used by the two default mascots, Shimeji and KuroShimeji
But the creators just pick one?
i guess so
Then why can't we just have all three?
but, if we had a setting for that, they would need to pick all of them
and then modify all of them instead of modifying just one to suit their needs
Do the creators pick one to include in their mascot?
i'm not a creator but i would think so 
I'm looking at the ant build.xml...
The only difference between the zips is that they change that one file...
And if the creators just choose one in the end, why don't we just include all of them in one zip and tell them to choose after downloading it?
listen i didn't create this program i don't know what the thought process was 
Well, I guess my point is, there's no reason to, so there's no problem in releasing three different versions for different OS's
It'd only be 3 instead of 9
i just find having three zips for even one OS a lot
But when are they used?
I guess for the default ones, but is that really that big of an issue?
Oh, I misunderstood
I mean 3 archives in total. 1 for each OS
i am tired right now and i feel like my brain is being assaulted 
kk
I'm scared
I accidentally turn on my autoclicker
Now Discord is reading some channel on hear in tts, and I can't shut it up
Sweet silence
I'm back. So what's the state of the Java 21 merge?
The falling forever bug happens with the Java 21 build, still waiting to see if it does on the Java 11 one
welp
Is this two Evilings, two Broken Neurons or one of each?
(Ignore the Neuron behind the other one)
No way to know
Exactly. The Broken Neuron uses the Eviling's climbing sprites
I mean, more than just that, if you look at the image folder
I guess the Broken Neuron is missing some sprites, so it just has the Eviling's for now. Maybe Pachha will make the missing ones at some point, unless it's supposed to be like that
There's a bug that can cause a shimeji to run in place
I added it to the bugs txt
By the way, is there any progress on fixing the memory leak or merging the Java 21 version?
Did you manage to fix any of those bugs? The memory leak especially is really inconvenient.
promote made the broken neuron from paccha's WIP neuron sprites, plus finished eviling sprites to fill in the missing spots; paccha would have to remove the color from the remaining neuron sprites to complete the image set
i don't know whether she draws the color on a separate layer or something, but that would make creating the remaining sprites easier because she could just disable that layer
That doesn't seem like it would take that long.
Did you look at the file with the bug info?
i don't even remember your having sent it
I did, but it has been updated since then so I can send the up to date version
okay
There should be an option to set a hotkey to make more shimejis
Left-click the tray icon.
I know that does that, but it would be evven more convenient to be able to just press a button at the side of my mouse or something, which works anywhere
They are mostly just ideas
i'm pretty sure the memory leak is not a memory leak at all and is instead just bad optimization
It seems very much like a memory leak, at least on Java 21
i'm currently adding the GraalJS stuff manually so i'll see whether it causes a memory leak
maybe there's something being used improperly or some resource not being closed
in the GraalJS stuff, i mean
or outside it, too
It does take a while to grow in memory, so make sure to test it long enough
I think it's also dependant on the amount of shimejis
which is why i thought it was bad optimization
It just seems to grow faster the more shimejis there are. The actual memory for the shimejis themselves isn't that much I don't think
might be because each instance of Script now creates a new thread
Interesting. Well, whatever it is, it is pretty inconvenient to have to restart it a couple times a day
if i can't make it not create new threads for each script, i'll have to rework it to close them once it's done with them
Would be interesting to see the whole thing properly multihtreaded at some point. I could see how many shimejis a core i7-12700K can truly handle
The falling forever bug is still definitely existant in the Java 21 version. Haven't confirmed it with the Java 11 jar though
actually, it's just one extra thread for the whole class; my bad
Ok, that shouldn't take 8GB of RAM
There's a shimeji behind everything again
Seems like the shimeji that's behind everything is now falling forever behind everything
The Java 11 shimejis are now constantly ending up behind Discors and all other windows
Script doesn't spawn any new threads, as far as I'm aware
yeah already figured that out
For our purposes, the polyglot contexts don't need to share any state, but they can't be accessed concurrently
it's still really slow though
ThreadLocal just makes sure no two threads share a context
What is?
our usage of graalvm
it feels like it is much worse than nashorn when a lot of mascots are on-screen
Memory-wise?
I'm not sure exactly what, but my instinct is that the memory leak would be from the JNA stuff
And what do you mean by this?
i was taking the GraalJS stuff from your PR manually since the maven commit would have made it hard to merge
yeah i noticed
Yeah... sigh
is there an issue
Nah, it just took a long time to reach a solution that took like 10-20 lines of code
At least I'm fairly confident I know a bit about what's going on
what was up with that temporary variable map bit, by the way
i commented that out as a test and the script engine shat itself
this
Grabbing a shimeji will not start the grabbed animation until the shimeji is moved
Turns out this was actually not a bug, and that the idle dragging animation itself was.
For the default Shimeji, at least. Paccha's were made with that bug in mind.
Coincidentally, though, both the default and Paccha's Shimejis had a separate bug related to the dragging animations, so I fixed those on both.
Does not render over Minecraft in fullscreen
I think that's just how Minecraft's fullscreen works. There exists a mod for borderless windowed Minecraft, though, which would probably fix it.
Falling forever bug (when the displays have had no display from Windows,
i have no idea what you mean by "when the displays have had no display"
Non-bugs (such as feature requests and general info):
- Single threaded
Do you want single-threaded? This confuses me because you said a few messages after this that it would be "interesting to see the whole thing properly multithreaded".
bug report management is hard 
When the script engine evaluates a condition, the condition is in the bindings, so it tries to evaluate itself to evaluate itself
Cue recursion
That took a while to figure out

I think nashorn may be lazily evaluating it while GraalVM is eagerly evaluating it
So I had to do that to fix it
Maybe I can get it to lazy eval, though
i don't know what those mean 
honestly i think using nashorn would be easier
it requires fewer changes, there's already a maven artifact, and it is made in jdk 11 so we can support more total java versions
if we used graaljs, we would only be able to support java 21
i am looking to support up to java 21 but not only java 21
I mean, it should be working with GraalVM, and I think it's worth it anyway, as it's actually maintained so we are sure it won't break it the future
of course, the nashorn maven artifact won't let us support java 8 anymore, but i'm willing to make that sacrifice
the nashorn maven artifact is maintained as well
???
i think the last update to it was actually pretty recent
well i couldn't find any old enough versions on maven 
wait that's graalvm jdk
not graalvm javascript
What's the artifact name?
graalvm has a version for every java version i'm pretty sure but i don't think graaljs does
org.openjdk.nashorn:nashorn-core:15.4
whoops meant to reply to you with that 
okay it's not as recent as i thought but it's more recent than the official jdk's nashorn
I mean for graaljs
Well, that's cause nashorn is completely deprecated
it was removed only because it was hard to maintain, but i never found any reason besides that
But that means it's not being maintained
brother you used the artifacts yourself why are you asking me 
not by the official jdk
Because I don't wanna pull up the project cause I'm lazy af right now
yes i know i already saw
again, it's a more recent version than the one from the actual JDK
... if i had to guess
yep
It doesn't seem like it's maintained, though
If it's not being maintained, what's the difference
even still, it's faster than our current implementation of graaljs 
I still haven't looked into that much, so I'd have to debug it
But I think it's worth it to put in some more effort for a better solution rather than just taking the quick solution
i think so too but i'm not adding it until it's actually the better solution
Regarding the graaljs stuff, why do you think it wouldn't support any older java versions?
because the oldest version of org.graalvm.js:js (https://mvnrepository.com/artifact/org.graalvm.js/js/19.0.0) didn't compile with java 11 for that exact reason
not exactly the oldest because the names of the previous versions in the version list make me think they are betas
yeah they're release candidates
not actual releases
so i'm hesitant to use them
What compiler?
Was it GraalVM?
Also, I'm not really sure why you're hung up on not being able to use older java builds
The 1.6/1.8 versions prompted you to go download them
i upgraded from 1.6 to 1.8 because 1.6 disgusts me
and jre 1.8 is the oldest version what can be downloaded easily
But why do we have to support Java 11
i am looking to be able to use newer java versions with the program, but not to have to compile it in those versions
Why?
because i feel like most consumers are going to be using jre 1.8 since that is basically the consumer version of java
plus i don't want to stray too far from what the source does in this aspect
Uhhh
the jump from 1.6 to 1.8 doesn't bother me much since i heavily doubt anyone has java 1.6 now
did i say something weird
I have never heard of this
it's called the java runtime environment
it's meant only for running java applications
the jdk, the java development kit, is meant for developing them
also i think setting up the jdk involves extra steps like setting the JAVA_HOME environment variable
We don't need the JDK for the end-users
That's the site that still only mentions Java 8
That link only talks about Java as a whole, really
oh okay
I think we should just target newer versions of java
And prompt the user to get them if they need to, like the current version does
we have an exe with the JRE bundled so i'll have to figure out how to replace that
I didn't see anything like that when I disassembled it
frickin' original shimeji devs
As far as I could tell, it just checks for a java version and prompts them to download it if they don't have it, and then run the jar if they don't
you mean if they do
... i mean, i do want to encourage persons to install java
i don't even remember where i found that exe honestly
may have been the google code page for the original project
yeah thought so
maybe we should just leave it as-is so it doesn't take up a lot of space
unless it tells the user to install a specific version in which case we need to update which version it says
I still like the idea of native images
Would do away with all of this trouble
Just for reference, the native exec I made, while not completely standalone, is about 15 MB
I would need to catch up with what you're doing to work further on it, though
Including other bugfixes
this is why i'm bad at collaborative programming; i just keep adding changes 
I'm the same
I mean, I just haven't programmed much because of reasons
I do like to think I'm pretty well-versed in general programming knowledge/theory, though
I guess just let me know when the repo is more up-to-date
You said you like more high-level programming
indeed
I tend to like the lower-level stuff, myself
So I can try to work on the memory leak problem
i just like to think that most high-level things are guaranteed to work the same on every platform because that's how they are supposed to be
in practice, though, that's not how it seems to work
I mean, it depends
i tried to use the same AWT-related approach with the linux port as i used with windows and it did not work out at all
the images never got cleared
each sprite just ended up being redrawn on top of the previous one
Higher-level stuff allows the compiler and libraries to do more heavy lifting with cross-compatibility and the such
I do think we need to comment a bunch, so we can try to refactor native library stuff, if we can
Well, for many other reasons, as well
though i'm not saying that i'm not at all experienced with lower-level stuff; i once used JOGL on a project what i commonly view as my magnum opus even though it's a fork just like almost all of my other repos
Fuckin' JOGL...
Although I end up fizzling out on stuff, I've tried a bunch of low-level projects for fun
i stopped using it when i switched from Swing to JavaFX and realized that JOGL didn't have good JavaFX support yet
in fact, it had none at all and i had to use shoddy third-party libraries to get it to work on JavaFX at all
Including OS and compiler dev, microcontroller programming, digital circuit design for a CPU, and other stuff
well, actually, it did work without third-party libraries, but barely
So, I think it's fair to say I like low-level stuff
i end up fizzling out on stuff too
I blame the bipolar II
i blame the adhd
Also that
But, anyway, you can leave some of the more low-level stuff to me
that's good, because i wanted to continue using native stuff for the windows images/translucent windows but they just didn't appear on java 11 when i used it
i added a todo comment for that
Yeah, let me know when the repo is up-to-date, and I can work on it
I don't want to get into any merge conflicts
So I'll wait until you push all of your changes
Btw, are you pushing everything directly onto main?
... Yyyyyes...
tsk tsk tsk
at the very least i tried to make separate branches and do PRs for that magnum opus project what i mentioned
though the PRs are probably enormous
the main branch for that repository was last updated 3 years ago and the swing-to-javafx branch was updated 5 months ago
I mean, I'm not one to criticize. I suck at properly using git
i've gotten better at it
I've only really used it once for an internship
i used to push fucking COLOSSAL commits which changed every fucking file at once
And I was basically working on that project alone sooo
Anyway, keep me posted. I've got to eat and stuff
oh it's been up-to-date for a while
Oh, and just for future reference, when are you usually working on this?
i'm just wondering whether i should push a module-info.java file 
later in the day when my classes are done
timezone?
Ah, so it's like almost 8?
it is 8 for me yes
Holy shit it's 8 and I'm a commuter and I'm still in my college's cafeteria.
i need to leave 
kk. I'm basically a NEET right now, so I can work basically whenever I'm up. I'm in MST
ogey 
do you know how to use java modules
i want to push a module-info.java file just for the sake of having it
Nah, I haven't worked with Java since high-school
okay i'll refrain for your sake
I mean, I can figure it out
it would be a hindrance though
I spend a lot of time looking at random language topics anyway
Cause I like learning new programming languages
Just read up a bit about it. Why would we need one as this isn't a lib?
i got Stockholm syndrome for Java modules after working with JavaFX
It's just for exposing classes and the such, right? I don't think we need it, because it's not like anything's gonna use this as a dependency
I mean I tell Windows to not draw any picture on the screen, by telling it to turn off the displays. Recently I've also noticed a possible connection with coming back from remote desktop, but that one might not exist.
This is a note about it being single threaded, it would indeed be cool to have it multithreaded
I should maybe rewrite some parts of the bugs file to be more clear.
Rewrote some parts to make them more clear and added a section for things that have been fixed/work as intended (now outdated version)
Just noticed a couple spaces missing. I think my spacebar key is slightly broken. Been broken probably since I made the dataset for my Evil Neuro TTS (had to write the metadata manually)
For some reason the shimejis just like to end up behind the Discord window
Seems like the borderless windowed mod is the fix. Cool.
By the way, it's pretty funny how these shimejis are the one thing absolutely destroying my remote connection, but they are so cute and fun that it's totally worth using the remote connection at a reduced bitrate.
I dragged around some text to test. It turns out dragged text is counted as a window, so the shimejis stand on it
Here's an even newer more up to date version with better formatting.
Anyone who might know of bugs not listed, it would be good to get them to be known, so they can be fixed.
Is there any progress anywhere by the way?
We'll keep you up to date
The Java 11 shimejis are now behind everything.
I don't think I've ever seen a shimeji transform on it's own, are they supposed to be able to do that?
In case anyone doesn't want to scroll all the way back up to download whats out
#1174291909066375199 message
For the best experience I'd recommend the partially experimental Java 11 compatible jar too, as it fixes many bugs with the release jar
It is here #1174291909066375199 message
It does need the release version's files though
Is there a way to make them appear over full-screen games?
What kind of fullscreen games?
minecraft for example
Minecraft requires a borderless windowed mod to make them render on top, as seen here
ah ok, thanks! I'll go look for one
that'd be great
https://modrinth.com/mod/borderless-mining/version/1.1.8+1.20.1 This is the mod I used
Thanks again!
No problem, I like helping with computer things. Especially this thing
My remote connection is once again dying from the amount of shimejis moving around
these mfs
i dont have a lot of assets done for her so she mostly uses evil's
but thats decent so far
I think it already looks great in this early state
Well keep making it then. As you said, it'll only take 4 years, so you should try to get it done in those 4 years
sure thing
By the way, have you noticed any bugs or other odd behavior or just behavior that should be changed in the application itself?
I'm keeping a log of bugs and things
i dont think i did, except for those you already listed
Ok, I guess my list has a lot of the existing ones then
yep you did a good job
I'll keep monitoring it for more, and update the file to match
Speaking of it, here's the latest version, it has a couple more bugs and things
im pretty sure ive seen it here but not in this txt unless im just blind but they constantly mess up standing/climbing on windows lol
its always somewhere a bit up there for them
especially here its obvious where the window is
this one
Are you running it on the Java 11 runtime?
You can check pretty easily what the Java version in the PATH variable is, by going to cmd and running "java -version"
mine's still 8th lmfao wait
Oh, that could be it
So now it's using the Java 11 runtime?
Check it from the command line, unless you used the batch file method to manually set the path for Java
im sorry what
Open CMD, and do "java -version"
That is the correct runtime, the issue might be settings in the shimeji application, here
What was the scaling at before?
1x, i only changed the check from nearest neighbor to bicubic filter
Did they become less crispy then?
dont think they did
Try restarting the application
still the same
That reminds me of analog compression artifacts. Could it be the The Clown specific fix?
man why does everyone's system have different bugs 

There is just so many combinations of hardware it's hard to know if it will work the same everywhere
At this rate we're gonna need to detect the hardware in every system and just have different fixes for different hardware
this is why i prefer to use higher-level stuff
they used to be somewhat this size on my old laptop but now theyre like this here 
at the same time, its weird that they crisp, they def were just upscaled fow whatever reason
given that the higher-level stuff works the same on every system, that is
do you know what the dpi of your current display is
nah
do you know your screen's resolution and physical dimensions
i think i can calculate dpi from those
17" and 1920x1080
is that first one width or height
it might be but i need to use google to find out 
Apparently PPI and DPI is the same thing
And mice use it for some reason
anyway the default PPI from what i understand is 96
mine is 240 according to Java AWT, and paccha's is 130 according to some spec
I have no idea what mine is, but I have 2 displays with pretty different specs and they look pretty much identical
I wonder whether I can change my computer to emulate 130 PPI so I can test it...
Resolution probably
Prob'ly.
But why do only some systems have issues with it, is it the GPU or display that's causing the bugs anyway?
i first need to calculate the resolution from my screen's dimensions and 130 PPI so i can set my resolution to that
Are you both using laptops?
I don't think I even have a GPU.
An iGPU usually counts
yeah i'm using a thinkpad p15 gen 1 laptop
It being GPU doesn't actually make sense, unless you run AMD, as I'm on Nvidia and Intel
Then it could be the issue if Paccha uses an AMD GPU too
If it's not GPU, but both of you use a laptop, it could be a laptop screen issue
the thing is, though, the issue is not present for me anymore since i fixed it
it is present for paccha though
and i believe you have said you didn't have that issue on the latest version what i sent
It could be that the issue works differently on different PPI then, on some hardware common on your 2 systems, that mine doesn't have
that first thing is why i am trying to test it on 130 PPI
It seems like it works well on all systems Leotaris has tried so far though, and one of those was a laptop
So probably not laptop screens
It could be that, so try to get your screen to that to test. I'll add this to the bugs txt
What CPU do you have? That could technically give some info
Also Paccha, what hardware do you have?
well just google ASUS Vivobook X1704ZA-AU123
There might be multiple models, the best way to check is trough task manager. Just press ctrl+shift+esc
uh aight
12th gen intel core i5 1235-u
intel iris xe graphics
what else
Core count and RAM
16 gb and 10 cores
So it's not AMD at least, but we technically have other things. Like the RAM, do both of you have specifically 16GB?
And the iris xe might be an iGPU, so that should be checked
I do have an iGPU on the secondary diplay, but it's just a UHD 770
My RAM is also 8GB on one system and 32GB on another
Both of the systems I've tested work fine, so I don't know what causes it
it is iGPU in fact
If The Clown has iris xe graphics, it could technically be that
he also has this issue?
Had, before fixing it in such a way his system works
mhm aight
yea
do they seem to move too much or too little when you drag windows which they are on
e.g., if a mascot is climbing a window and you drag the window up a bit, does the mascot move upward a bit more/less than it should
it seems the same as before to me
so they are moving at the correct rate
that is not similar to what i had
yours seem to just be not interacting with the windows in the correct positions, but that's it
mine was a scaling issue
uh no mine's exactly scaling issue
they interact with windows normally once i switched to java 11
oh i don't mean the mascot sizes
oh well
though i did forget about that so thanks for reminding me 
what i mean is
java 8 seemed to only ever return 96 PPI when it was used to check the PPI of the current display
but switching to java 11 made it start checking the actual PPI
there was a lot of complicated fuckery which made the program think the bounds in which the mascots could move was much larger than it actually was
so they kept falling out of the screen
once i fixed the falling stuff, they would not interact with windows correctly because they thought that the windows were in completely different positions than they actually were
to be specific, they thought the windows' positions were multiplied by the scale factor of the screen's PPI divided by 96 PPI, though i feel like i suck at explaining this
so i'll try to use an example
there's a window at (x, y) with dimensions (width, height), and the screen PPI is 240
240 PPI is 2.5x larger than 96 PPI, so they think that the window's position is at (2.5 * x, 2.5 * y), and it has dimensions (2.5 * width, 2.5 * height)
this affects how they interact with it; when standing on it, if the window is moved, they will move in the same way, but 2.5x more than the window did
it feels like this sort of thing happened when i run it on java 8 i guess
it also means that they don't appear to be standing on it at all; they just hover above empty space, most of the time
that last aspect is somewhat similar to what you have, but none of the rest of it is similar

i hope i don't have to make it use only java 8 again
What if Pachha tried the Java 21 version, would that have the same issues?
i tried it, it runs the app but mascots wont appear
Was it on Java 21?
yeah
i don't think the changes what you made would have affected that, but the fact that it lacks some of the changes in my latest version would affect that
i had the exact same issue actually
So there could be some issue common to your systems
that was the first issue when porting to java 11
paccha if ur wondering about the github btw , its not availabe rn
im planning to make another one so im gonna give invite to you
oki
Well, getting the application itself to work would probably be a main priority right now, so the Github stuff might be secondary, but whatever gets done I guess
To summarize:
DeathByPrograms and Superbox are able to run the GraalJS version (also known as the Java 21 version) fine.
Paccha and I can run the Java 21 version, but no mascots appear because it lacks the fixes for Java 11 which I had in my version.
DeathByPrograms, Superbox, and I can run the Java 11 version fine.
Paccha can run the Java 11 version and it works somewhat fine, but the mascots are too large and crispy, and they interact with windows in the wrong locations.
Seems like that matches the current situation pretty accurately
they interact with windows just fine i told u 
i thought you sent a video of them hovering above the windows and to the left of them
yeah but i was using java 8 at the time
once i switched to 11 they appeared large but the windows issue is nonexistent
That one was just a Java 8 compatibility issue
i'm tempted to fix that even though we might not support java 8 in the future
Fixing the compatibility with later Java runtimes should probably be prioritized
yeah i'm going to look into the large mascot issue
Sounds like a good idea
though, before i attempt to fix it, i should probably ensure that it's not on my most recent version
so i'll send a build of it for you guys to test
Ok, which Java?
works with Java 11 and up
Should I try both 11 and 21?
im havin issues
all my neurons are weuro
here it is
did u enable evil?
Choose a Neuroling from the tray icon right click menu
have you tried enabling more shimejis in the mascot chooser
@supple sigil @edgy siren
how do you enable?
i just ran the exe file and it gives me weuros
dont know how to fix this unfortunately
Right click on the icon in the taskbar, select "choose a Neuroling"
task bar?
the bar at the bottom of the screen
it uh
click the arrow
send a screenshot
it might be in there
It might be behind the arrow icon
OHHHHHHHHHHHHHHHHH
wow
im so dumb
tysm lmao
It's that easy
It's as shrimple as that!
Anyway, back to the previous issue
here's the latest build; it also includes the neurolings because i test them in this repository and didn't bother removing them before building
plus, they have some fixes
can't wait to discover that i unknowingly made 20 breaking changes
(not really)
shes standing on the link popup 
hey she looks possibly normal-sized
no she isnt actually
Fuck.
The jar runs and shows up on both Java 11 and 21 for me
now i have to apply EFFORT 
also i think this is just an instance of Windows treating a lot of mundane things as window objects, like link popups and dragged text and the "Show hidden icons" menu on the taskbar
i'd hope so, since paccha's also looks identical to the previous version
if it looked different on yours but the same on hers i'd lose my mind
paccha is that using the most recent build
yea it is
okey
I'll run this version for a while to see if the memory leak still happens
Does the popup menu for the tray icon also appear bigger, Paccha?
but they appear on 21 for me btw
curious
as well as the menu that shows up when u right click on em
hmm
one of the java 11 port issues was that the popup menu appeared in the wrong spot due to the screen resolution scaling PPI stuff, but it was the correct size
so now i'm thinking
maybe this is an issue with Java AWT itself on your specific system
so what does it mean
if it's a problem with Java AWT itself then i might not even be able to fix it (not without reverting to java 8, at least), but maybe the internet can prove me wrong

If it's an issue with Java itself, it could definitlely be Win 11 compatibility
Do you have Windows 11?
nope im on 10
I have Win 10 on all systems
Well, that rules out Win 11 specific issues for Pachha
It could be some specific driver on the system, those are system specific usually
i sure hope so
Or hardware specific
i also hope that's the reason why the shimejis keep falling in that corner for you since i have never seen that happen on my system
It could also be a 2 screen thing, unless you've tested two screens. The usual way it happens is, that I have it running for many days, and I shut down my displays (not the PC) for the night or when I go away, then when I come back, they can fall forever
In that specific corner only
by "shut down the display", do you mean something like turning off the monitor's power or do you mean having the computer go into sleep mode
I never have my PC go into sleep mode, but I make it not output and power off the displays
how do you make it not output to the display
do you unplug the monitor from the computer
I have it set in Windows so that when I press the power button, it turns off displays.
Here
Hang on a moment.
Couldn't you test whether it's a 2-screen issue by just disconnecting any other monitors?
It would take multiple days of normal use just to test, it's super random
also, when testing, try to test a specific variable and don't introduce extra variables
the fact that it could be either a multiscreen issue or a no-display issue or an issue from running for a long time isn't as helpful as it could be
I haven't actually seen it happen with the Java 11 version, only the Java 21 and older builds
so maybe try disconnecting other monitors and refrain from turning off the display at night to test whether it's just an issue caused by running for a long time
or test one of the other variables instead
It sometimes goes away with another display cycle
Holy hell. This took me 2 minutes of holding "Home" to get to get to the top 
Just ask for the download if you need it
i wish discord had a button for returning to the original post, especially since we can't search in individual forum threads
the most recent download isn't here anyway
this is the most recent release
But it's in the same Gdrive
Oh, is it? 

This is still Java 8? 
The release download is
the one on the gdrive yes
Not for long. 
But the Java 11 jar works better in most cases
rdy to test again 
hi leo
Oh, get the latest test build then
i sent the latest build a bit up in chat
Any chances to run it with 21? 
Yep!
Yes, the latest jar works with 21
roger
thank you
Cool. I will wait then. 
well its pretty much the same but it runs on 21 i guess
i should probably push my changes to the neurolings to the new repo
and works better
It might still be a bit before there is an update to add the new jar to the main download, but it's not too far
the latest build runs on any JDK from 11 to 21
yeah this
The one currently being tested

i hope i can get the portability issues fixed before we decide to release neurolings again
i don't want to add the latest build to the repo if it has bugs on some specific platforms
#1174291909066375199 message This is the one that works with all JDKs from 11 to 21
Oh
though this confirms that the EXE says the wrong java version number so i will definitely need to change that
i wonder in what year that EXE was built
Ok, lets see how many Java processess can 6 core handle
Seeing Neuro@s jumping from one monitor to another is a one hecking cute detail
glad to know i didn't break that
keeping track with 3 monitors is killing my neck rn 
how does everyone have multiple monitors 
is this a common thing 
Yes, multiple monitors is a common thing, I think
Seems fine
I refuse to work with only one
You know you can just make more of them under one process?
?
I'm not talking to you
... Have you been running multiple instances to get multiple Shimejis?
Yes. Im just running benchmarks
๐
Oh ok
Ok. Task manager crashed at 26 proceses
good luck keeping track of which shimejis go to which processes
Task manager can crash?
That's scary.
Nothing can save you now.
I once tried to see if more shimeji processes (2) would give more shimejis on the underpowered laptop, but desktop window management died
On my main system I run one instance on 11 and one on 21
But that is to test it
i recommend using only one shimeji type on both so you can more easily tell which is which, if you aren't already
I have two per Java ver, but the effect is the same
Ok, this is the limit. Which of the config setting is the ammount of nueros?
there's no setting for it
but left-clicking the tray icon spawns a random mascot from the enabled ones
It's not in the settings (not yet at least), just click on the tray icon
and right-clicking an existing mascot and clicking "Call another" spawns another of that mascot type
given what you're doing, though, i think you're looking to spam left-click on all of the tray icons until something crashes
Yeah. It would be easier if nueros wouldnt attack my tray
To make sure the tray icon is visible, right-click the taskabar and do stuff in the taskbar settings
you could move the tray icons to the main taskbar instead of keeping them in the "Show hidden icons" popup
The new build seems to be more optimized interms of resources, my RAM is no longer above 16GB all the time
Before, it was hovering around 20GB with 2 processes
i mean i did do minor optimization stuff but i don't think it would have affected it too much
Fixing the memory leak might have happened
I just love working under pressure
I don't see it leaking memory
Might replace the jar in my main version (Java 21) with this new one to get all the configs
It doesn't like those files for some reason (tried replacing the lib)
Wait. Shimeji actually uses GPU?
Oh wait, I might have the wrong files still
Oh yeah, since the first Java 11 test build
20% of my 3090 
1% 4070Ti
I got it to run on the old file structure (correct lib now)
Now I can see the version from the icons too
Oh, maybe it is because of this (double that on second monitor)
That's more like it
Now around 10%
Total GPU (full system) 30% across an iGPU (smaller monitor) and RTX 4070 Ti (larger monitor)
15% each
Technically two cores
And here's window management
Ok, system is starting to not like it anymore
Just replicated the stuck to cursor bug
These are all attached to the cursor, and I'm not pressing the mouse button
honestly, i don't think i'll be able to fix the cursor bug; i can only theoretically prevent it via optimization since it only happens when the program is lagging
Yeah, it's really laggy right now
On very powerful systems this is technically a way of multithreading (running more instances)
But I think it might benefit from better RAM for window management
Not sure though
They still completely stop when switching screens
I think the main bottleneck is moving around so many "windows"
oh wait i forgot to ask paccha to test something
i wanted to see whether the mascots were also too large in windowed mode
how do i even enable "windowed mode" for them
go to the settings and look under "Window Mode"
nope theyre normal size in there
okay thanks
Maybe it's using an incorrect display resolution in normal mode?
Check the environment data
AKA the reveal statistics menu option
oh hollup
first, they are large in windowed mode too
i was running the old version sorry
second, this i guess
What does it look like in non-Windowed mode

The environment doesn't match 1920 x 1080
it indeed doesnt
yeah i see that
So now we know what's going wrong

Now somehow just figure out why it's happening
I think it's setting the resolution of the environment wrong, causing the shimejis to get rendered in the wrong size and get blurred from pixel-aligning
That would fully explain the issue and it's effects, but the root cause is still unknown
I get the impression, that Neuron and Weuron doesn't clone themselves as much as the others
It's random, so it might just be random chance. There is also a cloning limit I think
it is? I didn't know that
Cloning is a behavior, and behaviors have chances attached to them
I wrote down what we know so far (I think)
I think the issue is with it setting the resolution of the environment to be different (smaller) than what's rendered
Seems like the memory leak is fixed
I can confirm that
That's a good patch
Now let's hope this bigger visual bug can be figured out
That for some reason is unique to Paccha's system
fun shimeji fact: it's possible for a mascot to have separate left and right sprites for any pose
rather than flipping the same sprite
Interesting.
Do you have any idea why the resolution of the environment would become that wrong?
I'll wait
never mind 
Ok
But at least we have some info better than the immediately visible effects
Knowing what causes the effects of the bug could help to find the cause of the bug, but without knowing Java, I don't know if I can get closer than this
Actually, could Paccha's PC be reporting an incorrect resolution to shimeji/Java?
That would explain why only Paccha has the bug
How would shimeji behave if it got an incorrect display resolution value from the OS, that doesn't match the actual resolution?
By the way, you might have accidentally patched the falling forever bug in the earlier jar, because I've not seen it happen with that jar
technically that's what java 8 did, but java 8 worked differently in regards to DPI/PPI
So what would happen if the Java 11+ version got an incorrect resolution?

Is it possible that that's what's happening to Paccha?
possibly
i am guessing that java itself is getting the wrong DPI/PPI which is why all of the collisions still work for paccha
they probably wouldn't work if it was on my end
Would it be possible to calculate the resolution instead of pulling it from the OS?
how else would i be expected to get the resolution
What does it currently do?
uses AWT and native Windows stuff to get the screen size
note that using AWT gets a smaller size, but that is supposed to happen because it's ignoring DPI-related scaling
or maybe i should say it's taking that into account by dividing the resolution by the scale factor
Could we somehow check what Paccha's system is reporting for resolution?
i'd say the statistics window already provided that
But that could techically be a calculation error somewhere, for some reason. I'll test something real quick and see what happens
Well, this happened
I changed windows screen scaling to 125%
Whilst it was running?
Yes
It really didn't seem to like that
It does the same even if I run it after changing it
Oh, what? I already tried changing it between executions.
It didn't look like that for me.
Well, I have 2 displays, I changed the secondary one
Changing on the main one works even runtime
I think it only checks for scaling on the primary display, not any others
i don't think paccha uses multiple displays though
and besides hers didn't look like that
Yeah, so that's clearly an unrelated bug


