1
Modification Help / Re: Face Player onDeath
« on: June 12, 2013, 02:40:22 AM »
... are you 100% sure you are activating the package?
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Modification Help / Re: Playertype velocity problems
« on: June 10, 2013, 03:55:17 AM »
I believe avoid can be multiple things, in fact I remember it being inside dumpConsoleFuncs...
That's really not important right now though. Just pointing it out.
Even though Port did a nice job summing up what raycasts do and how to use them, you must still be wondering how to implement it so that it activates when a player clicks. It's really easy- you can just package player::activateStuff(), do the vector math, and trace from there. Here's an example that I wrote from the top of my head:
Code: [Select]
... virtual string containerRayCast( Point3F start, Point3F end, bitset mask, SceneObject exempt=NULL,exempt2,exempt3,exempt4,exempt5,exempt6 ) {} ...That's really not important right now though. Just pointing it out.
Even though Port did a nice job summing up what raycasts do and how to use them, you must still be wondering how to implement it so that it activates when a player clicks. It's really easy- you can just package player::activateStuff(), do the vector math, and trace from there. Here's an example that I wrote from the top of my head:
Code: [Select]
package activateStuffPackage
{
function Player::activateStuff(%player)
{
%lengthOfRay = 4;
%start = %player.getEyePoint();
%end = vectorAdd(%start, vectorScale(%player.getEyeVector(), %lengthOfRay));
%hit = containerRayCast(%start, %end, $TypeMasks::PlayerObjectType, %player);
if(!isObject(%hit))
{
return Parent::activateStuff(%player);
}
//do checks & stuff to %hit
return Parent::activateStuff(%player);
}
};
3
Off Topic / Re: What are your phobias?
« on: May 31, 2013, 02:10:00 AM »
Insanely large things, for example, imagine skydiving through a thunderhead and then coming out the other side and looking up.
Being in the middle of a huge body of water, I have no loving idea what's under me. Imagine being at the bottom of the ocean by a seaweed forest...
Being in the middle of a huge body of water, I have no loving idea what's under me. Imagine being at the bottom of the ocean by a seaweed forest...
4
Drama / Re: dotdotcircle
« on: May 04, 2013, 08:59:17 PM »Computermix is a troll, the securecommandtoclient thing is an incident in which a player figured out the password to a secure server command that allows adding names to the player list GUI and messaging all players in a server that a player has disconnected/connected.I can guarantee you I'm the one that found that out. If anyone gets in trouble for that I'll take the hits. I'm not trying to troll anyone, sorry if I upset you siba.
5
Drama / Re: dotdotcircle
« on: May 04, 2013, 05:13:05 PM »
He was revoked for sending stuff to the master server (obviously), and he was also talking about some other jazz that involved loving with Blockland's exe, that could have contributed. Poor dotdot.
6
Drama / Re: Elite 100 - I don't even know
« on: April 28, 2013, 01:19:33 AM »What section was this thread in? Or was it locked.This one, http://forum.blockland.us/index.php?topic=226283.0, but its on the latest pages.
7
General Discussion / Re: Im sorry but I am getting tired of the engine limitations
« on: April 25, 2013, 04:40:32 PM »Can't you do it the opposite way though? The server could create a random seed and share it with the client.
I don't think I know what you're trying to say...
Roughly, every 20ms a function called CInput::createmove is called and it samples mouse input, keyboard, etc. and shoves it into a packet called a CUserCmd packet. Yes, a packet is sent every 20 milliseconds. Don't worry, with the help of delta compression the packet can be as little as one byte when you aren't moving or anything.
The part with seeds: When the command is called, an integer parameter is passed called command_number. This number is also used to store data with the multiplayer backup, but that's not important. Generation for random seed is 'MD5_PseudoRandom(command_num) & 0x7fffffff'. When FX::Firebullets is called (the tracers you see on the screen), it uses this seed to calculate the spread of the shotgun/smg/pistol or whatever to draw it instantly. The packet is sent to the server with the same command_num and the same calculations are done there, and then the bullets are finally traced with that seed, after all that compensation.
If the server sent the seed to the client, a ping of > 80 would make it look delayed and it might have an unnatural feeling.
To experience this yourself, do cl_predict 0 in TF2's console or similar. Movement, weapon firing, and other things will be delayed. Not sure if the cvar is restricted though.
8
General Discussion / Re: Im sorry but I am getting tired of the engine limitations
« on: April 24, 2013, 11:07:02 PM »
Slow projectiles can be fixed with raycasts, but it's sort of a halfassed solution.
What I've noticed: in a server with > 100 ping, there will be a delay between actual clicking->firing. This can be seen with the old school rifle. You can be aiming perfectly at the players (on your screen), click, but it will be delayed by 100ms regardless, and you will miss. It's like quake, you have to head your players by your ping. And that's no fun.
Here's what the source engine does to fix this problem:
When you fire, client sided prediction (for weapons) draws bullets instantly no matter what. It completely kills that unnatural feeling with that ugly 100 ms delay. But you may be thinking: when the server get's that packet indicating you're firing, it's going to trace the bullets late and just miss the player. Well there's also a fix for this, and it's called lag compensation.
Let's say you have 100ms lag, and 100ms interpolation period. The server, when it gets the firing packet, would "reverse" everyone's position based on that time (200ms). It would then trace the bullets then instead of with the current, real-time positions. If you feel like this is inefficient, well screw you, you go and google it yourself. Valve has all kinds of docs on this and how it works.
One more thing: how would the client render the fire of random things (cone spread, bullet spread)? Wouldn't the server and client have to have the same seed for random?
The sad answer is yes. This is a flaw in the networking code. The client must "send it's seed" to the server in order for the server to trace the same randomized bullet angles. Hackers have abused this method in many engines for no spread, unfortunately. But it's the only way for an efficient, good looking client prediction and realistic gameplay.
Blockland has none of these, so that's the reason there is no "no-spread" hacks/cheats, because random seeds are the current time in MS and theres no way to predict that efficiently.
What I've noticed: in a server with > 100 ping, there will be a delay between actual clicking->firing. This can be seen with the old school rifle. You can be aiming perfectly at the players (on your screen), click, but it will be delayed by 100ms regardless, and you will miss. It's like quake, you have to head your players by your ping. And that's no fun.
Here's what the source engine does to fix this problem:
When you fire, client sided prediction (for weapons) draws bullets instantly no matter what. It completely kills that unnatural feeling with that ugly 100 ms delay. But you may be thinking: when the server get's that packet indicating you're firing, it's going to trace the bullets late and just miss the player. Well there's also a fix for this, and it's called lag compensation.
Let's say you have 100ms lag, and 100ms interpolation period. The server, when it gets the firing packet, would "reverse" everyone's position based on that time (200ms). It would then trace the bullets then instead of with the current, real-time positions. If you feel like this is inefficient, well screw you, you go and google it yourself. Valve has all kinds of docs on this and how it works.
One more thing: how would the client render the fire of random things (cone spread, bullet spread)? Wouldn't the server and client have to have the same seed for random?
The sad answer is yes. This is a flaw in the networking code. The client must "send it's seed" to the server in order for the server to trace the same randomized bullet angles. Hackers have abused this method in many engines for no spread, unfortunately. But it's the only way for an efficient, good looking client prediction and realistic gameplay.
Blockland has none of these, so that's the reason there is no "no-spread" hacks/cheats, because random seeds are the current time in MS and theres no way to predict that efficiently.
9
Off Topic / Re: Scripting, coding, programming, etc.
« on: April 22, 2013, 12:19:40 AM »I find Cpp's syntax the most unnecessarily complex syntaxes in programming. I mean, it's bearly readable.Practice makes perfect, I guess. At the time when I began I had an extremely high interest in it and I just didn't quit. Eventually it made sense and I was having more fun than problems, and it was good from there.
Even ASM and Python (to me) look more readable.
10
Off Topic / Re: Scripting, coding, programming, etc.
« on: April 22, 2013, 12:11:44 AM »
What? Nobody uses C++? It's my favorite and I use it all the time.
11
Modification Help / Re: Compile C++ for use with blockland.
« on: April 19, 2013, 11:50:06 PM »
Short answer: Yes, it's certainly possible! And very cool.
In fact, I've been doing similar things for the past weeks now. PM me if you want more info.
I can't see how he could not have disassembled/reversed blockland's code (IDA pro? Ollydbg?) because if you want to call a function you're gonna need an address, you can find the function in memory/bl.exe and just use that specific address, or you can create a signature for it and sigscan for it when you inject the dll (a more dynamic way of getting addresses). If he didn't look at the code for blockland in any shape or form, I can't see how he could have gotten the function address in the first place unless he's using some method I don't know about. Am I missing something?
In fact, I've been doing similar things for the past weeks now. PM me if you want more info.
http://forum.blockland.us/index.php?topic=213238.msg6026557#msg6026557
yes
I can't see how he could not have disassembled/reversed blockland's code (IDA pro? Ollydbg?) because if you want to call a function you're gonna need an address, you can find the function in memory/bl.exe and just use that specific address, or you can create a signature for it and sigscan for it when you inject the dll (a more dynamic way of getting addresses). If he didn't look at the code for blockland in any shape or form, I can't see how he could have gotten the function address in the first place unless he's using some method I don't know about. Am I missing something?
12
Off Topic / Re: Favorite Game Engine?
« on: April 01, 2013, 08:28:51 PM »
I've worked with Source for such a long time and I love it to pieces.
13
General Discussion / Re: Do you think Badspot did a good job of Blockland?
« on: March 19, 2013, 04:51:07 PM »
I think blockland could use a better weapon system. I couldn't compare it to anything better than source because I've worked with source for a long time.
There would be two types of the same weapon: A third person model (world model), and a first person model (view model).
The first person model could be high poly because it would be the only model of that gun to be rendered in first person view. It wouldn't have to be the entire model either, as long as it covers the main details (example: the scout's scattergun first person model only covers the detailed parts to the left of the model, the rest is blank)
The third person model could be very low poly. Really just a separate model from the first person model with reduced shape quality. It would also have different animations so the original first person model could have separate firing animations while the third person model wouldn't. The exception would obviously be that you could only see it in third person (on other people's hands in the map, too)
So when you equipped this weapon, you would see the very detailed first person model. When you tabbed to third person or looked at another person with this gun, it would show the low-poly third person model. That way we wouldn't have to balance out detail and reduced poly.
There would be two types of the same weapon: A third person model (world model), and a first person model (view model).
The first person model could be high poly because it would be the only model of that gun to be rendered in first person view. It wouldn't have to be the entire model either, as long as it covers the main details (example: the scout's scattergun first person model only covers the detailed parts to the left of the model, the rest is blank)
The third person model could be very low poly. Really just a separate model from the first person model with reduced shape quality. It would also have different animations so the original first person model could have separate firing animations while the third person model wouldn't. The exception would obviously be that you could only see it in third person (on other people's hands in the map, too)
So when you equipped this weapon, you would see the very detailed first person model. When you tabbed to third person or looked at another person with this gun, it would show the low-poly third person model. That way we wouldn't have to balance out detail and reduced poly.
14
Modification Help / Re: Animations not working in 1st person
« on: February 03, 2013, 01:01:19 AM »
When I was interested in that custom player animations thing, I wanted to apply the same concept to weapons. Tried Shaper, but just like what you're having it didn't export any animations.
I did some more research on dts importers and I found a program called Ultimate Unwrap 3d. It's $50 to get, but it's dts importer is absolutely flawless and it can export to almost any format. I bought it myself and it works really nicely.
I did some more research on dts importers and I found a program called Ultimate Unwrap 3d. It's $50 to get, but it's dts importer is absolutely flawless and it can export to almost any format. I bought it myself and it works really nicely.
15
Modification Help / Re: Weapon Damage
« on: December 21, 2012, 10:17:06 PM »why don't you just define %directDamage all in one go?I'm well aware of better methods of doing this, but I split it up for the reason of the op's better understanding. It's just easier to get what I'm explaining imo.
Modified version inspired by phflack!