I have added a link to denis-takumi's repository on github.com. I have been off from LFS for a long time, sorry for not keeping the library up to date. Anyway, the work needed to update it is very simple and I think many members here can do it easily. I still receive email notifications of replys in this thread and private messages, so I'll try to drop by from time to time to update the first post if needed.
I have no clue how to properly do this.. Every time I try to process pack_cpp->Pos , dev-C++ generates some error which keeps me entertained for long Google periods.
That isn't valid C++, which is why it's complaining.
Pos is of type Vec - don't get confused by std::vector, which is a variable length array-like container.
Vec (along with Vector) is already defined at the top of cinsim.h.
If you want to grab the whole of Pos to store/use somewhere else, you should be able to do:
Vec Pos; Pos = pack_cpp->Pos; // Assumes pack_cpp is a pointer to a struct. If it's an actual struct object use pack_cpp.Pos
You can then access the values using Pos.x etc
Alternatively, you can just access the values directly:
float X = pack_cpp->Pos.x; // again, access members using . instead of -> if it's an object instead of a pointer float Y = pack_cpp->Pos.y; float Z = pack_cpp->Pos.z;
Disclaimer: the above *should* work, but I haven't tested it against CInsim as I stopped using it a while ago.
As a side note, make sure you're using a C++11/C++14 compliant compiler - it'll make your life much easier. Modern C++ is waay nicer to use than the old styles.
Although I need to verify the numbers it looks like it works yes. Thank you very much, I needed this completely spelled out information because I am too noobish with this and I am also not really planning to be pro with it either.
I just need a small app which controls the camera's on the client side for LFS streaming purposes and this is a new step towards full camera remote control
Also thanks to DANIEL-CRO & denis-takumi for the fast replies!
I am using Dev-CPP++ by the way because its the lightest editor which I could find. Didn't want to download and install hundreds of Megabytes of Microsoft tools just to make a tiny application. The same with this CInsim, it's, I think, OK enough for my needs.
If you are playing around with cameras, I attached sources of my Cameranaut tool.
( https://www.lfs.net/forum/thread/85921-Cameronaut-%28TV-camera-that-can-be-placed-anywhere%29 )
Code is really thrown together..I just wanted something to use for videos. Also I last looked at it long time ago so no clue anymore what excactly is in there But it does some basic stuff with camera (reading position, restoring position, pointing at car etc) so maybe there is some useful bits. Or something that puts you on completly wrong path, no guarantees.
You have InGameCam = 2, that is LFS TV camera, it can not roll. I think the only cameras that can roll is the free (shift+u) camera and maybe the cockpit view.
Not every value works or make sense with all cameras. For example the "Heli" camera always is pointed downwards so its pitch is always same.*
You can generally read all values but some sent values get ignored because they do not matter for that camera mode.
Basically for those cameras LFS controls how they move and insim can only provide new ViewPLID. (the viewed car) For really flexible camera work one must use the free shift+u cam.
*=interesstingly with rift one can "look around" in heli-mode, but normal player or insim can not.
Hhmm.. Well.. I request this CPP packet when I am in shift-U mode and I have set some random roll value where the camera actually is on its side. LFS just remembers the last InGameCam/PLID setting prior to going into shift-U mode. I forgot to debug Flags, edited my message but there you can see that I am actually in shift+U mode.
I just tested and it does not save roll. Position, FOV etc all gets restored but roll is not restored.
3) Then I tested with LFS-Record ( https://www.lfs.net/forum/thread/72001 )
That tool can controll camera and it CAN set roll. (I do not know if it can read back roll, I think the program has no use to do that)
My guess is that other programs could probally SET roll, but can not read it?
I think that is a bug or missing feature..
I think I have another bug concerning car contacts. Multiple car contacts [like two GTRs crashing into each other] causes a HLV wall packet instead of multiple CONs.. I think, not sure yet. I need to confirm this first with another tool and this might be a good one.
The car-contacts are reported in filtered way. I guess otherwise during bumpdraft (pushing) there would be lots of spammed packets. There is speed (and time?) threshold (it is somewhere in insim.h) but it definately works.
Great
Also I have a small question:
My insim apps always crash when going back/forth in replays or when playing them at too high speed.
I think it has to to do with packet buffer overflowing or so.
How to handle that?
For example see a few posts up, the insim camera..works okay but except the described problem.
If I remember correctly the X-Y-Z Positionin example also has this problem, but I can not test right now.
This hasn't been active for a while but I am feeling like writing a super cool InSim lib and basing it on C++ but using SWIG to generate a wrapper for a bunch of other languages so people can use it and extend it to write whatever else they want. I'm assuming since this is open source I can borrow your work. Let me know if otherwise is true