The online racing simulator
C++ - CInsim - A basic C++ InSim library
(157 posts, started )
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.
Thank you! Nice to see you active again!
Update insim.h to 0.6G18
Include insim.h 0.6H
Add GetLanguageCode method for new NCI packet
This C++ gives me headaches.

How do I output/cout the contents of the IS_CPP Vec Pos of LFS?
Why don't you replace Vec by 3 floats (Pos by 3 ints).

...
Vec Vector;
...

to

...
float VectorX;
float VectorY;
float VectorZ;
...

and then print each value.
Or alternatively define a corresponding struct.
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.

If I use a simple internet example;


std::vector<int> myvector;
for (int i=1; i<10; ++i) myvector.push_back(i*10);
std::ostream_iterator<int> out_it (std::cout,", ");
std::copy ( myvector.begin(), myvector.end(), out_it );

replace this with


std::vector<int> pack_cpp->Pos;

Then I get


expected primary-expression before "pack_cpp"

I tried 500 million other combo's as well.. It gets a bit frustrating. I don't know what it wants from me, I know however what I want from it Smile
myvector is class, while pack_cpp->Pos is just 12 bytes of data (3 ints). Really the easiest way is to have 3 ints.
u can create class
put IS_CPP in construct
write any method for prety print
Quote from cargame.nl :

std::vector<int> pack_cpp->Pos;


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 Smile

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 Tilt 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.
Attached files
LFS_cameronaut random sources crap.zip - 871.9 KB - 374 views
Hhhmm this looks useful! Thanks Thumbs up
Not that I am going to use it but whatever I do, camera 'roll' keeps being reported as 0 while it's not. Rather strange, almost would say it's a bug Taped Shut

---

void case_cpp (struct global_info *ginfo)
{
cout << " * IS_CPP (camera position packet)" << endl;

struct IS_CPP *pack_cpp = (struct IS_CPP*)insim.get_packet();

Vec Pos;
Pos = pack_cpp->Pos;

int RI = pack_cpp->ReqI;
int X = pack_cpp->Pos.x;
int Y = pack_cpp->Pos.y;
int Z = pack_cpp->Pos.z;
int ViewPLID = pack_cpp->ViewPLID;
int InGameCam = pack_cpp->InGameCam;
cout << "ReqI: " << RI << endl;
cout << "X: " << X << endl;
cout << "Y: " << Y << endl;
cout << "Z: "<< Z << endl;
cout << "heading: " << pack_cpp->H << endl;
cout << "pitch: " << pack_cpp->P << endl;
cout << "roll: " << pack_cpp->R << endl;
cout << "FOV: " << pack_cpp->FOV << endl;
cout << "ViewPLID: " << ViewPLID << endl;
cout << "InGameCam: " << InGameCam << endl;
cout << "Flags: " << pack_cpp->Flags << endl;

/*
ReqI: 1
X: -30744156
Y: -66646282
Z: 1551386
heading: 48448
pitch: 65238
roll: 0
FOV: 44.4
ViewPLID: 3
InGameCam: 2
Flags: 23049
*/
}

Roll is this axis:
http://www.photopoly.net/wp-content/uploads/11072011/9.jpg

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.
Hm yes something is strange:
1) Request camera packet with Insim Sniffer ( http://insimsniffer.codeplex.com/ )
Roll is always 0.

2) In my cameranaut tool I store the complete camera packet (instead of 'extracting' x,y,z and so on) like this:
struct IS_CPP *cp = (struct IS_CPP*)insim.get_packet();
newCam.CPP = *cp;
myCameras.push_back(newCam);

And then load it back like this:
void loadCamera (unsigned camNumber, float speedMulti)
IS_CPP cam = myCameras[camNumber].CPP;
insim.send_packet(&cam);

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..
Quote from Gutholz :Hm yes something is strange:
1) Request camera packet with Insim Sniffer ( http://insimsniffer.codeplex.com/ )
Roll is always 0.

OK thanks for the confirmation!

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.
I made bug-thread for camera roll: https://www.lfs.net/forum/thread/88680

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.
Quote from denis-takumi :https://github.com/turbosnail/cinsim

- Updated to 0.6M
- Added Light control methods
- Added pure JRR method

Great Smile
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.
Quote from Gutholz :Great Smile
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 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.

mb u post backtrace ? its would be great
I will try to make some example, might be few days/weeks
upd: full JRR implement
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 Smile

C++ - CInsim - A basic C++ InSim library
(157 posts, started )
FGED GREDG RDFGDR GSFDG