The title says it all. Swing has several solutions to make LWJGL views a decently performant component, but no such project for JavaFX really exists, just proof of concepts with questionable performance.
What under the hood reason leads to the difficulty of achieving this compatibility?
So what are folk's opinions on the Drag and Drop API for JavaFX? I wasn't the biggest fan of having loads of separate methods that can be called separately. So I did a small proof of concept of a builder-like way of doing the drag and drop logic to see what it would look like and, tbh, I quite like it.
Am I in a minority here, or would there be some potential in fleshing out a builder-based way to do it?
Label draggable = new Label("Drag Me!");
ObservableList<String> items = FXCollections.observableArrayList();
ListView<String> dropTarget = new ListView<>(items);
Drag.enable(draggable)
.payload("Drag Payload is doing stuff yay!")
.onStart(context -> System.out.println("Drag Started on payload!"))
.onEnd(context -> System.out.println("Drag ended with mode: " + context.getTransferMode()))
.init();
Drop.enable(dropTarget)
.onDrop(context -> items.add(context.getPayload().toString()))
.init();
I do not know if I am the only one who actually liked the doormaker? But I have sat silently on the sidelines, genuinely confused why people had issues with him.
Sure, he exhausts cards first turn, but I genuinely used that as a positive to make the best version of my deck I could by exhausting all the chaff out (always got a few draw cards to make my exhaust choices a bit easier).
But not only do they remove him, but they replace him with the Aeonglass and, I do not know if I am just built different (as I have seen little to 0 complaints about the boss on this subreddit) but the Aeonglass can go back to the pits of hell from which it was spawned!
Me and my friend have tried duo beating him, we were doing like 300+ damage a turn in some of our runs... and every time we come up against this Hourglass with aspirations, it utterly demolishes us.
We just had a run end where we went into that final fight, I had 2 oblivion and an upgraded shroud, daughter of the wind and a beating remnant... and we STILL got our arses handed to us...
Does anyone else think the Aeonglass is the spawn of satan? Or is there something I am missing thats leading me to a serious case of the "skill issues"?
Hi there,
I'm a Aerospace Engineering Educator, minor contributor to OpenRocket, and someone who has been passionate about rocketry for about as long as I can remember. I am posting today to open both a discussion / PSA on the topic of LLMs being utilised in the creation / further-development of Rocket Designing software.
Disclaimer: I am NOT speaking on behalf of OpenRocket, or my Institution in any way, shape or form. These are my personal beliefs / opinions.
I will be blunt with my opinion on the matter, by saying the most obvious statement of my career...
Rocket Designing Software is used to design rockets...
The reason I say this is, frankly, I believe that LLM (AI) is slowly becoming a problem for Rocketry-Related software. There is still a lot of debate over the merits of LLMs being utilised in software development, and I am not the philosopher nor authority to make a judgement call on that. That said, I believe Rocketry-Related software needs to be treated with a bit more care than most open-source projects. Why?
Rocket Designing Software is used to design rockets...
Even over in OpenRocket itself, there are some contributors who (quite rightly) see it as a hobby project. Something we all do for fun. I agree with this in principle, but there is an elephant in the room that, respectfully, I feel a lot of people keep forgetting...
Rocket Designing Software IS USED TO DESIGN ROCKETS...
This software, if it goes wrong, can get people hurt. It is hopefully rare, with people utilising common sense, not trusting software / simulations blindly etc. However, the fact remains that these software will estimate critical properties such as COP and COG. They perform simulations of the rocket trajectory / stability.
I know first hand how easy it is to mess these things up. I have seen some wild stuff in my time working on OpenRocket bug fixing. I have seen magic numbers being used to make pseudo irrational numbers to maximize the number of unique points hit on the cross sectional perimeter of the body tube sections, I have seen save-window logic that actually gave me a headache reading, hell... Ive seen code copy pasted to the point of being 400+ lines that could have been one 70 line while loop... code of any project has had the potential to have warts long before LLMs...
I always teach to my students the, in my opinion, most important thing a student needs to learn to think if they wish to do well in Aerospace Engineering...
"Everybody in the room is an idiot, including me!"
We need to constantly have the voice on our shoulder stating "This could be wrong, double check". I personally believe that LLMs rip this state of mind from us, and replace it with some horrible hybrid between "yes man syndrome" and the Dunning–Kruger effect. It causes this state of mind where you assume not only you are right, but also are able to do things way beyond your skill level.
This is even worse in those who blindly use LLMs to make "mega refactors" or, dare i say it, entirely new projects. So, in my opinion, for someone to use these tools to aid in the work of a software designed to build rockets, is reckless at best, negligent at worst. I do not wish to call out any particular project as, whilst there have been ones very recently, I have seen quite a few.
Full refactors of OpenRocket in another language, PRs in Open Rocket with 10000's of changed code lines. All done via LLM agents by people who either have 0 context of what they have changed, or have just enough experience to (in my opinion, dangerously) assume they know enough to "trust what the LLM has written".
I will not condemn the people who make these projects / propose these refactors, but I will ask all of your a question?
Would you trust such software? You are using this software to build rockets, trusting they are accurate. There are no regulators telling us what the software needs to be / not be. There is no great authority that will prevent us from making big mistakes. You just have to act on genuine faith / the maturity of the project / projects.
So... would you trust Rocket-Designing Software created mostly through LLMs?
Additionally, what effect would the following factors have on your trust / distrust of such software?
- The amount of time it took to make (e.g: A few months vs a few days)
- How much testing has been done on the software internally (including if they added unit testing / integration testing).
- How much code they have added in one go (i.e. loads of small changes, or giant 1000s of lines changes that took an hour or 2 to do with an LLM).
I do not think I have to say what my opinions on the matter are, as I hope they have been made apparent above. But I would honestly love to hear the community's thoughts on it too.
Thanks for reading, and see you in the comments!
So i have learned a decent amount about Resolve over the last few years. But one thing that has always annoyed me is Handwriting animations all seem to involve hand drawing the effect over the text in some way or another.
​
Afaik, noone has made a plugin or automated solution, but I am willing to give it a go. I am a developer with over a decade of experience, but I am relatively new to automation in resolve.
​
My question / request for help is figuring out how the solution would work conceptually. I.e. I dont need to the code itself, I can do that graft, but some brainstorming / guidance on how best to approach the solution would be appreciated.
​
The end result i would want to see is a simple "write the text in, and it automatically hand draws it onto the screen over x amount of seconds"
So something bugged me about the timeline section of the latest video.
It was said it didnt match up with the employee's story as they said they had hauled for "4 hours".
But I think the employee mispoke and, when queried, said yes in a classic "dont disagree" blunder.
He actually said he told his boss around 11pm he had to get up early for another job...
Now the Eugene store closes 7pm usually... so 11pm would be 4 hours later...
Lets look at the timeline now:
- 9:45ish: Truck leaves salem store.
- 1 hour and 16 minute drive between stores (thank you google maps) leaves us at.... oh.... interesting... 11pm....
- Say the unload takes half an hour ish... 11:30pm
- 1 hour and 16 min drive back to salem and... oh... look at that... the time is 12:45am-ish.
Timeline seems to line up quite well when you account for the "4 hours" line. 👀
This is honestly driving me nuts. There does not seem to be solid documentation anywhere.
I dont want someone to point me at something like Jdeploy. Or some other super duper all in one solution. I am learning. I care as much about the process as I do the final product. If people cannot learn the core concepts of building JavaFX apps that are self contained, all these "all in one" solutions will slowly lose contributors as the core knowledge is lost imho... I.e. im wanting to avoid "bus factor" by learning how to do it myself from scratch.
How do you build a self contained package / where are all the good resources / documentation that contain information on building self contained packages. Somebody help me please, as i feel im going nuts 😅
I will be blunt... since LLM posts have become more common, this place is getting near insufferable.
LLM posts, LLM replies... can we just agree to ban them and call it a day?
We already are in a niche thats seen as "crackpot" by a lot of the math community... can we not add fuel to the fire by letting a load of nonesense LLM posts litter the subreddit please?
