My Open Letter For ACC

Ah really interesting...
So the calculations and tables reside outside of unreal (as I thought), but are they then input into unreal as they are calculated?
My way of thinking is, unreal ultimately needs the physics data to run.
I know unreal is not calculating or producing physics data, it is merely accepting the data in, as it is calculated by your own tables/calcs/physics engine.
Am I correct with the above?

 

So the data look-ups are in unreal, but the calculations are in the ACC exec.
So unreal needs the calculations exec and in order for the physics to run, it needs to plug those calculations into the tables and into the UE4 engine to make everything happen (or vice versa).
If this is correct it is what I was of the thought of all along. Basically UE4 takes the values and is able to use those values to present the physics to the player.
So Unreal is containing LUTS and data tables, and then the ACC calculations basically feed back and forward to get the final calculated values...?

Basically, when I hit a kerb and the car interacts with that...the physics engine is fed from the LUT in UE4, runs calculations, binary data is fed back to UE4 and we then have the physics presented on screen as we drive. So UE4 is like the "container" for all this to happen?
Or is it a case where UE4 manages graphics and stores some LUTS, and then the ACC calculation exec actually re-calculates and manages the physics element, independent of UE4?

 

What? The calculations are performed on the run by their own engine. The relevant data for ue4 may be shared and used to output what they have to output meanwhile. Quite simply. Ue4 does nothing with the data, judging what he said.
At most, ue4 may be used for the mfd pit interactions or stuff like that.
Also the ambient should be on their engine side. I mean wind direction and intensity, the position of the sun. Basically everything that has anything to do with the car, I think it's on their engine. He said it.
When you hit a kerb, the physics are doing their job and they share only what is perceivable by the player.
That is managed by ue4 to translate it into human understandable images and sounds. But maybe ue4 doesn't even deal with the audio output.

 

This is done by FMOD

 

Let me add that is done beautifully

 

You are wrong

ACC physics was lifted straight from AC1. Physics is implemented in a static lib and data is sent back and forth from UE4 that is only used for graphics. UE4's physics engine was later used to implement audio query for things like dynamically changing reverbs.

 

Yeah I was of the understanding that the numbers need to be plugged into UE4 in order to give the graphical representations of car movements and so on. I wonder how that is done...maybe just a graphical setting and pre-canned car movements. It is done pretty nicely.

 

Thank you for this clear answer. So it is like 2 engines running in parallel. UE4 for graphics and then ACC's own library and physics tables etc?
So when people sometimes suggest that ACC is limited in some areas of physics, say, kerb hits being too harsh due to unreal engine...this is obviously not possible??

 

nope

First, "tables" or LUT usage in AC/ACC is minimal. LUTs are used for things like engine torque or to conveniently represents simple relationships such as tyre degratation.. but everything else is "equation" based.

In AC1 car data was coming in using INI text files.. in ACC we were forced to use UE4 data system to input values.. so car data input is done through UE4 data editor instead of text files.
Surely @aris has tons of stories about this.. he had built tons of tools in AC1 to autogenerate a lot of the INI files for the cars.. when we switched to UE4 he lost all that tooling and everything became manual. Good question for his next stream.

Some things are really well done in UE4 such the curve editor and general handling of data, with a nice system to evolve/add/remove data fields without destroying the existing files. With INIs it was all done manually to make sure that cars using an older format could still be loaded.

But ACC UE4 side simply loaded the data from the UE4's data system and forwarded them to our "AC1" engine that did the rest of the work. Same goes for things like the track geometry ACC UE4's side would read the triangles of the 3d model and sends them down to the physics that will create its own "version" of the world.

This might sound like a weird approach and it is if you think about developing a game from 0 in UE4 but our situation was quite different as we came from a software like AC1 that was designed from the start to have totally separated "worlds" for physics and graphics.. thus making it quite easy to lift the entire physics system from AC and "plug" it in UE4.

so ya, you are pretty much wrong in your entire theory... but the theory was solid and made sense without knowing the details of the history and the events that brought ACC to life.

 

GONKO:

You are software developer and you don't know that you can do Assembly Code in all IDEs?

Pascal Example: (I don't know Basic example)

Program Example;

Begin

ASM

mov eax, 1
xor ebx, ebx
int 0x80
END;

end.

In this example, your compiler will pass everything in ASM section in x86 assembly code and will compile in fscking pascal.

You are always running things in parallel. You can run nuclear bombs simulations, and use Unreal to show you some graphics. You can't look what .exe is running and conclude anything from that info alone.*
*(this is not true, because you can look what that .exe is calling...)

 

I work in tech/software, but I'm not a software developer. And I certainly don't have expertise in game development, this is why I asked for some clarification. And it has been really interesting to understand and learn. And of course thanks to @stefanoCasillo for the detailed explanation.
I love learning new things, and this is really interesting to know. Thanks to everyone for the input here.

 

I was very happy to hear of getting some news finally, in whatever form (I've played ACC since early access and am coming close to 3k hours, I remember a time when there were some kind of roadmaps...). I'd take everything at this point. "Would be great to have another small roadmap with at least a hint of what and when to expect things" I thought. Though your reply and promise of a roadmap is already 4 weeks old now. To be honest I'm not even surprised. This is exactly the level of "teasing" and not giving information at proper time and place that Jardier was writing about. It's just sad and I'm getting more and more frustrated not only with the lack of information but mostly with how unprofessionally you guys handle this.
Please don't take this personally in any form or shape. It's just the same old story and we're getting disappointed by you guys again and again. I love this game and still think it's the best sim (for me) out there. There are a lot of studios that show how to communicate properly with your community and if you need help with it, don't be shy, let me know.

 

Hey Firmi,

I understand how you feel. The roadmap is still being worked on and will be released as soon as it's ready. I can't set an ETA on the roadmap at the moment but rest assured that we're working to get this to you all as soon as possible.

 

@Rwaggy

Correct, it will be done, when it is done, not a second before.

When I was doing industrial automation commissioning, I would always have some guy, who didn't know his a** from a whole in the ground, continually asking me, "when will it be done".
And depending on how much he was interrupting the debugging, I would reply with,... something like,..."the sooner you let me do my job, the sooner it will be done, and not a second before.

Guys like this always remind me of a comedy movie, were some spoiled kids are continually asking,... "are we there yet, are we there yet, are we there yet ".

 

Since I'm a game dev myself and know the processes very well, I can tell you that it's not too hard to properly communicate what is going on, especially when you got a dedicated person for that kind of stuff. Giving an estimate with some kind of disclaimer, that of course releases can be postponed for a lot of valid reasons, is not even that hard and an easy job to do. Kunos did that already at the beginning of ACC but then stopped for some reason. There are many options on how to do it and to keep the effort to do so very small.
You should also know, that in your (tbh bad) example, no customer will give you the job if you can't at least define a rough window of when your work is probably done (otherwise it's probably not very professional). Those deadlines are even harder in the gaming industry (in most cases and especially with AAA games and publishers). Luckily Kunos has, it seems, the freedom to take a lot of time for patches and release of cars etc. which is fine and should be normal (which unfortunately it isn't always). But not communicating with the community, especially nowadays with all those socialmedia options at hand, well, I won't repeat myself and the others here now...
Sadly you didn't understand the point of my and several other posts here in this thread and even try to insult people, but I like my daily dose of Dunning Kruger so I have to thank you for that laugh I had

 

Wait to Rennsport Jardier, the best thing you can do...

Being an absolute ACC fanboy I moved to iRacing two years ago with no regrets (even paying +600€ in tracks/cars).

As you wisely said: if wouldn´t be LFM or Simgrid, ACC would be completely dead (but with tons of potential...).

It´s a shame honestly.

 

Nothing charging a lot more for ACC,... wouldn't fix

I do get "the point", of some here, but simply agree to disagree,...

Insults were never intended on my part, lighten up guys,...

Maybe a road map to the "road map", would satisfy some here,...

 

The “it will be done when it’s done” or the “ACC would be completely dead” are both extremed reactions to the lack of information about ACC future development and content.

Kunos clearly changed the communication approach it had in the past regarding future updates and content to be added.
In the past Kunos was keen to tell the players what the future would bring, announcing partnerships, development progress or involving the players in future content, like in all these examples:

https://www.assettocorsa.net/forum/...license-alfa-romeo-officially-revealed.11537/

https://www.assettocorsa.net/forum/...censing-agreement-with-the-nissan-brand.8191/

https://www.assettocorsa.net/forum/...-corsa-welcomes-lamborghini-automobili.19255/

https://www.assettocorsa.net/forum/index.php?threads/assetto-corsa-welcomes-porsche.33544/

https://www.assettocorsa.net/forum/...upcoming-ferrari-70th-anniversary-pack.46040/

https://www.assettocorsa.net/forum/...-6-early-access-release-delay-spoilers.54943/

https://www.assettocorsa.net/forum/...ne-early-access-release-6-further-news.54993/

Unfortunately, this type of communication with the players diminished as ACC progressed and from some time it halted completely, to a point that only through Stephane Ratel’s slip of tongue 8 months ago was the GT2 made known and, upon that, Marco Massarutto confirmed that both the GT2 and 2023 GTWC season will be added to ACC in the future.
Since then not a single line was said about it by Kunos, not even announcing that the GT2 and 2023 GTWC cars are coming to ACC.
Early this year there was a very short tweet about the Ferrari 296 GT3 but nothing else.

In all I think that an official announcement about what is reserved for the future, not requiring a schedule or concrete date, would not take long nor would require detailing all the future updates, would not be a bad idea at all and the players would be more aware of ACC development and more involved with what to expect for the future, bonding players towards a future commitment with ACC and a sense of continuity.