Irrlicht Engine

The printf_s is simply a lack of compiler recognition. But the other errors seem to be really bad. Brutal pointer hacking?

hybrid wrote:The printf_s is simply a lack of compiler recognition. But the other errors seem to be really bad. Brutal pointer hacking?

i havn't changed anything, i was just trying to compile example1 has anyone got a devC++ project of any of the examples they can throw me? seems there's something i'm missing..

Edit: HAHA never mind, good old MSVC Eh ran it through msvc and compiled first time... thanks anyway guys

Sorry I was sure I removed the _s, or I did atleast with the SVN version. I recommend you use the SVN because it has many new features. (Link is on the first post)

EDIT: Woops it appears that even on the SVN I forgot the printf_s on lines 44 and 47. So simply change those to printf with the _s.

BlindSide wrote:Sorry I was sure I removed the _s, or I did atleast with the SVN version. I recommend you use the SVN because it has many new features. (Link is on the first post)

Yeah, im using the svn.. its on line 47 of netmanager.cpp

--Removed--

Edit: Once again, it's my own stupidity... i forgot the media files ignore me

im back! you're not on irc so ill shout here.

I have a problem, as soon as a client connects, the server crashes..

heres what the console says:

i can't debug it, because msvc throws random exeptions about materials as soon as i run the program, but thats not where its crashing.. my program is basically the same as the example but i added a username system.. maybe ive broken something..

help?

I've just started using irrNet, and here are several issues I've hit:

a) not all printf's are under "if (verbose)" - which gives lot of messages on stdout/stderr potentially unwanted
b) there is no way to get size of the data in InPacket
c) there should be a way to read block of data from InPacket
d) there is no support for wchar_t* strings

I've changed NetManager and Packets to solve these issues, but I feel that this should be done in an "official" version of irrNet.

Other that those, it works perfectly Great job!

Alexione if you wish to only use the easy packet sending features I recommend irrNetLite (Somewhere in the project forums too). It comes without all the other stuff and is more streamlined for sending custom packets.

Blindside!!

I debugged, as soon as a user joins, it crashes here
line 1399 of Netmanager.cpp... any ideas what's causing this?

BlindSide wrote:Alexione if you wish to only use the easy packet sending features I recommend irrNetLite (Somewhere in the project forums too). It comes without all the other stuff and is more streamlined for sending custom packets.

Actually, I will need both of it, and that is why I had to adopt irrNet a little

Interceptor, a dynamic cast will not crash. It might eturn a null pointer, though. So did you check for it befiore using the result?
Hmm, what happens if I dynamic_cast a null-pointer? Should work, but you might want to test the pointer before, also.

hybrid wrote:Interceptor, a dynamic cast will not crash. It might eturn a null pointer, though. So did you check for it befiore using the result?
Hmm, what happens if I dynamic_cast a null-pointer? Should work, but you might want to test the pointer before, also.

I went through it thoroughly with him and all the parts that cast a ISceneNode to an IAnimatedMeshNode would crash. Im not really sure why?

You have to compile with RTTI enabled. Otherwise it might raise unknown type informations.

cast from 'void*' to 'irr::u16' loses precision

i'm getting these all over in 0.36 and svn

How can I fix this?


Edit :

It happens when event.peer->data; is cast to u16. ( (u16)event.peer->data )

Never had this problem before..

Thats GCC being annoying.... Its possible to comment that line, it should be ok...
I think there is a compile flag to stop GCC from frowning on casting issues, look for it somewhere.

b) there is no way to get size of the data in InPacket
c) there should be a way to read block of data from InPacket
d) there is no support for wchar_t* strings

All of these are possible using the string sending functionality, it will store the size in a u16 first and then output the string which is just a char array. So it is possible to store wchar_t* and any other block of memory inside the char*, and obtain the size of this block and reprocess it when you recieve it on the other side. Though automated transfer of wchar would be nice...

Maybe I should change all the printf's to cout's to please C++ fanatics... lol