where? i cant think of any except etk driving school which wouldnt have a bus, or garfield heights, and some other mods, but i was also talking about vanilla,
I could think of maybe 3 things that could be: 1. An elevator, either for a vehicle or the "human", it could maybe be used for career mode, for maybe buildings that would have interiors (i doubt this tho) 2. Car lift, maybe in the garage that we own, or potentially a new garage, where maybe we would tune/ upgrade our cars, again for career mode probably, or a prop 3. Stationary crane, either prop or part of map, but question is why would we need crane, what would be the use Another thing we can find out from that clip is that it uses electric motor (from ui app), which usually isnt used by cranes?
I love the old Berlinetta --- Post updated --- what if beamng added a program where kids can learn about cars in a fun way?
Thank you for clarifying, this is why I like the Beam team, they're actually communicative and honest
Whether the CEF performance overhead is inherent or not, depends on how much optimization we manage to squeeze out of it. Whatever much we manage to gain, can not be called 'inherent'. Whatever we're not able to optimize, then I guess you might say it was. And yes, integrating the CEF imagery with the render engine can be quite expensive. This is part of why our game UI is limited by default to 1080p UI resolution: to limit the amount of pixels we need to manage, which is one of the big factors driving down UI performance. Regarding switching from Angular to Vue, we have never used Angular, but AngularJS. AngularJS has been abandoned, which puts it in a bad position. Vue happens to be able to be more performant in many scenarios compared to AngularJS, so we hope to gain some snappiness on that front too. And a migration from Angular to Vue is less disruptive, more progressive, than a migration from AngularJS to Angular for example.
A question coming from a failed web dev: what is the biggest issue with the CEF-based UI like the one in Beam? For example, from the user's perspective, one of the worst parts of Beam's UI is how terribly laggy the vehicle selector is, even on high-performance machines. Is it just because the UI has to load numerous configs and image previews (which can amount to hundreds of megabytes!), or is it something deeper inside how the whole UI is scripted or maybe even the way AngularJS itself handles such tasks?
Ngl a European destruction derby update would be great, a new banger track and some iconic classic eu bangers to race. Then as a bonus an AI function to allow all vehicles to go after eachother like banger racers do.
if we get eu derbys we need a us map (that is not the texas one*) that could includes a demo derby oval with a race that has barriers up to make it a figure 8 track *becuase the texas map that includes a demo derby ring is only that there is nothing else to it except abandoned buildings and dirt tracks we need a normal farmland area that would have a dirt track like what ive been suggesting for a while now midwest usa
Thanks for the insight. I've been using React for so long I forgot that there was a difference between Angular and AngularJS. If I understand correctly, the decision to use a web-based UI was made early in BeamNG's development after replacing the Torque3D UI for in-game tasks. What was the driving factor behind the decision to use CEF/Web UI over alternatives?
The vehicle selector has to handle... I think more than 1 thousand vehicle variants. It's a ridiculous amount of data to begin with. And we are not considering mod support. Imagine the numbers of a mod hoarder . I wouldn't be surprised to see 2K-10K variants in their UIs. How many cars do other games show in their vehicle selector? Still, the vehicle selector has received optimization effort over the years. I've personally spent a good amount of time optimizing the LUA backend of the vehicle selector (shaving around 1-2 seconds of load time, if I recall correctly). Other colleagues worked on the optimized scroller system. Etc. But it's still a ton of data. And we're adding probably dozens more variants every year, so it's an uphill battle in addition to being a hard battle already.
Cant this be addressed by making the game load at the beginning only the base cars without their configurations, and when you click at the wanted car, then make the game load all its possible configurations? I'm sure it can be improved a lot from what it is.
It´s important to realize that, sure, these technical discussions can be interesting. Questions like "how to optimize this particular menu", "how to optimize the whole UI". It's a conversation we could have (and that we're having internally more frequently than you might expect). A conversation that I would likely enjoy, being a programmer myself. There's a number of ways to approach these problems. However, lack of technical ideas is not the bottleneck. It's lack of time (aka, excess of other tasks): As a dev team, we must prioritize the thousands of tasks in our internal To-Do list, some of which would be UI optimization. How important each task is, how much time we estimate it'll take, and how uncertain that estimation is. You juggle all those factors and all those tasks, then come up with a plan to use our limited resources as wisely as possible, to get the best possible overall result on each update. Or in my previous words, "we're doing what can be done within our means". I don't mean to shut down the conversation of how to optimize the UI or anything I'm only trying to shed some light about why the currently ongoing improvements to UI are not as impactful as we would all love them to be.
The Wentward is not a school bus in anyway. Even it was yellow, yellow bus is a yellow bus. Not a school bus.