A repair pakage as a bomb.. yeah i can see that..
« Reply #120 on: February 19, 2013, 09:13:05 PM »
This forum is now archived!
- Welcome to the archive!
News:
The 3DRad community can be found at classdev.net.
- 3D Rad - Free 3D game maker - Forum >
- General Category >
- 3D Rad - User-created Sample Projects, Scripts, Tutorials >
- MouseLook, WASD drive
Author
Topic: MouseLook, WASD drive (Read 13078 times)
« Reply #121 on: February 20, 2013, 11:43:36 PM »
Excelsior!
I had it working with bones, but the shadows of the fans didn't look right. The shadow model can't use bones. So I scrapped the bone animation system and switched back to seperate skinmeshes, and wrapped them in a class. After finally discovering I had uninitialized variables in the class, viola!
I had it working with bones, but the shadows of the fans didn't look right. The shadow model can't use bones. So I scrapped the bone animation system and switched back to seperate skinmeshes, and wrapped them in a class. After finally discovering I had uninitialized variables in the class, viola!
A repair pakage as a bomb.. yeah i can see that..Repair package as a junk pile... ammo crate as a bomb. Tank as an amusement park ride, squirrel as a flying squirrel, etc.
Ship.zip
(2084.63 KB - downloaded 37 times.)« Reply #122 on: February 21, 2013, 03:51:29 AM »
Added object grabbing. Capslock turns it off & on.
Ship.zip
(2098.38 KB - downloaded 32 times.)« Reply #123 on: February 21, 2013, 12:41:21 PM »
cool i like it.
PS if you include the skinmesh in the zip file ( if it's different from my design) you also need to include the `index` .jpg file, other wise it wont show up as a skinmesh in the open skinmesh dialog.
PS if you include the skinmesh in the zip file ( if it's different from my design) you also need to include the `index` .jpg file, other wise it wont show up as a skinmesh in the open skinmesh dialog.
« Reply #126 on: February 21, 2013, 03:00:20 PM »
Nice work. About the controls config though, I think we should adapt RobertooMolvadoo's Scripted Configure Controls. Eliminates all those EOIs. Sure, manually networking will be tricky, but I bet it could be done.
« Reply #127 on: February 21, 2013, 05:16:30 PM »
Yes i cant see any reason not to use it ..
I'll need to add to this so it also checks for proportional controls like joysticks & game-pads.
Easy enough to do.
I wanted to script a config controls too but decided not to bother.
I'll need to add to this so it also checks for proportional controls like joysticks & game-pads.
Easy enough to do.
I wanted to script a config controls too but decided not to bother.
« Reply #128 on: February 21, 2013, 05:21:24 PM »
Ah actually the script doesn't eliminate any EOI .. it's just a replacement for the configure controls object.
This is a good thing, cause it gives us full control over the process, unlike the built-in object.
This is a good thing, cause it gives us full control over the process, unlike the built-in object.
« Reply #129 on: February 21, 2013, 06:05:50 PM »
But it can - it can send user input to another script much like the EOIs would.
« Reply #130 on: February 21, 2013, 06:26:18 PM »
OK 
to rephrase .
It can replace EOI objects..
But the use of EOI is because they have built in networking.
This script doesn't, so the inputs would need to be networked.
In my ID remapping, both process's are used, i use, EOI only for it's local input & configure-ability of the controls.
For networking i use the text array system to transfer EOI data to the host to eliminate EOI objects for every player.
Using this script, i can replace a few EOI objects, but still need to network the input data.
It's big plus is it allows full scripted control over the configure process.
to rephrase .It can replace EOI objects..
But the use of EOI is because they have built in networking.
This script doesn't, so the inputs would need to be networked.
In my ID remapping, both process's are used, i use, EOI only for it's local input & configure-ability of the controls.
For networking i use the text array system to transfer EOI data to the host to eliminate EOI objects for every player.
Using this script, i can replace a few EOI objects, but still need to network the input data.
It's big plus is it allows full scripted control over the configure process.
« Reply #131 on: February 21, 2013, 08:26:59 PM »
Script objects have networking ability. This is a proof of concept, that networks control of a car, without EOIs.
« Reply #132 on: February 21, 2013, 08:58:44 PM »
No no no.
You missed one small (big) detail ..
The networking is done using script commands, ( same way my ID remapping does it) to send data.
Jestermons POC is using the
and the client is using
PS Jestermon & i are both doing it that way for the same reasons...
So saying "script objects have networking" .. yes they do have networking script statements, for both inet-float-array and the inet-string-aray networking.
You missed one small (big) detail ..
Quote
I had a few headaches using iNetArrays from the client to the server, so instead send the control info via a string to the server, where it is parsed back into float values
The networking is done using script commands, ( same way my ID remapping does it) to send data.
Jestermons POC is using the
Code: [Select]
iNetFloatArraySendEx(0,9,0,false); on the server to transfer data to the client.and the client is using
Code: [Select]
iNetStringSend(S,0,true) to transfer data from the client over the string network system.PS Jestermon & i are both doing it that way for the same reasons...
So saying "script objects have networking" .. yes they do have networking script statements, for both inet-float-array and the inet-string-aray networking.
« Reply #133 on: February 21, 2013, 09:22:40 PM »
You say I missed something, and then went on about how networking can be done with a script, although strings must be used. If I'm missing a detail, you forgot the part about pointing out that detail 
.