[QUOTE=Jcorp;46450271]Not strictly Unity, but relevant to my project so hey-oo.
Here's some early (art person states that it is INCREDIBLY WIP) art for the two playable characters.
(it's kinda big so I won't lag the page by thumbing it)
[url]https://dl.dropboxusercontent.com/u/107588088/BigDamnCharactersWIP.png[/url]
It's odd giving someone a backstory you've written and then watching them make a pretty picture out of it.
As for something more programmer-y, I've done the "Emergency Drop Turret" that the guy drops when he's below a certain amount of health (the woman gets the gun)
[img_thumb]https://dl.dropboxusercontent.com/u/107588088/Turret_Laser.png[/img_thumb]
It bobs up and down and shoots laser beams out of the red bit, but I've got a headache so like hell am I making a video on it.[/QUOTE]
Nice!
Where did you happen to find the artist btw?
anyone have any tips for making 2D cars understeer/oversteer?
Working on drop packs more.
This drop pack refills your health, and your shields also start recharging, when you interact with it.
Also kills you if you stand underneath it.
Watch on Chrome for 60 FPS.
[video=youtube;nBAdqBunQt0]http://www.youtube.com/watch?v=nBAdqBunQt0[/video]
Have any of you found issues with the number of gameobjects you can have in a scene? (specifically in 2d)
Is it advisable to split your game into multiple scenes? And if so, any way to have a seemless/continuous open map?
There's some good news for those who don't have a Visual Studio Professional license but want to move away from MonoDevelop for good, well now is your chance.
Microsoft has released a fully-featured IDE free which includes all features from Professional edition except for smaller teams. This also including the ability that allow extensions to be used, including Visual Studio Tools for Unity.
[url]http://www.visualstudio.com/en-us/products/visual-studio-community-vs[/url]
Oh and there was some news about Microsoft open-sourcing .NET on the server side and adding cross-platform support. Guess there's going to be less of a reason for anyone NOT to use .NET.
It's compatible with UnityVS?
I've installed the extension but this keeps opening 2012
You installed VSTU in both Unity and VS and set the IDE in Unity to "UnityVS" (I think that's what it is?), right?
Yeah, i'll unistall vs 2012 and resintall unity vs
I saw that I can color some gameObjects with red color if I create prefab and then delete it. Nice for marking non prefab objects :).
[QUOTE=LuckyLuke;46442292]Even with its flaws, would you recommend using default Unity networking or Photon for just a simple game where there'll only ever be two players connected?[/QUOTE]
For now, use an alternative to Unity's built-in networking.
How do I access values and variables contained in other scripts?
I am working on a shooting script that shoots the bullet based on where the character was last facing.
I've got a crude direction check in place, however I've had to re-declare KeyCodes in the shooting script (attached to my character, who also has a HP and Movement script), which is not ideal at all. How do I avoid that?
(naturally it goes without saying that I'm a C# noob)
[lua]
entity.GetComponent<Type>().variable
[/lua]
That var must be public, and you should know the type
[QUOTE=gonzalolog;46505117][lua]
entity.GetComponent<Type>().variable
[/lua]
That var must be public, and you should know the type[/QUOTE]
Yeah, I was reading up and GetComponent seems like the only option
Thanks for the help
[editline]16th November 2014[/editline]
Just came back to get at it. Having a problem though!
char_move.GetComponent<Character_Movement>().left
(with char_move being my gameObject, Character Movement being the script, and left being the keycode, which is public)
How do I implement this into my script? What I'm doing atm for direction check is making it so that an input swaps out a bool, but this change broke it
[code]
//this needs keycodes declared in this same script, unless I get them from char_move
if (Input.GetKey(left)) bFaceR = false;
if (Input.GetKey(left)) bFaceL = true;
[/code]
I'm now taking a crack at the bot AI for Orbital Assault.
I have totally scrapped the previous code and started from scratch. The new bots are using a technique called Hierarchical Task Networks, which are a form of planning used by many AAA games such as Killzone, Transformers, and more.
The plan is to have bots be mostly autonomous, but to also allow those bots to take orders from a higher-level Commander AI (commands like Explore, Defend, Pursue, Escort, etc)
At the moment, I've got basic wander behavior for the bots, and code to scan for and target enemies.
Bots now take all other players into account when firing at opponents, searching for a position with line of sight to the target so that they do not accidentally fire upon allies. I demonstrate this in the following video by being a dick to my ally and blocking his shot. He often moves out of the way in order to have a clear shot to his target rather than attempting to shoot through me. (bots do not yet actually fire their weapon, but the basic behavior is in place for it)
Bots also now maintain a minimum distance from their target. I demonstrate this by getting up in my opponent's business, like a weirdo. He consistently attempts to back away from me to a distance of at least 5 meters.
[video=youtube;NO0iny1qMDk]http://www.youtube.com/watch?v=NO0iny1qMDk[/video]
Aaaand of course I've just discovered that my octree implementation is slow as balls (using an octree to store AI waypoints, which are used as basically movement hints for the bots)
*facepalm*
[QUOTE=KillaMaaki;46506995]I'm now taking a crack at the bot AI for Orbital Assault.
I have totally scrapped the previous code and started from scratch. The new bots are using a technique called Hierarchical Task Networks, which are a form of planning used by many AAA games such as Killzone, Transformers, and more.
The plan is to have bots be mostly autonomous, but to also allow those bots to take orders from a higher-level Commander AI (commands like Explore, Defend, Pursue, Escort, etc)
At the moment, I've got basic wander behavior for the bots, and code to scan for and target enemies.
Bots now take all other players into account when firing at opponents, searching for a position with line of sight to the target so that they do not accidentally fire upon allies. I demonstrate this in the following video by being a dick to my ally and blocking his shot. He often moves out of the way in order to have a clear shot to his target rather than attempting to shoot through me. (bots do not yet actually fire their weapon, but the basic behavior is in place for it)
Bots also now maintain a minimum distance from their target. I demonstrate this by getting up in my opponent's business, like a weirdo. He consistently attempts to back away from me to a distance of at least 5 meters.
[video=youtube;NO0iny1qMDk]http://www.youtube.com/watch?v=NO0iny1qMDk[/video][/QUOTE]
What's going on with the FPS prefab? Haven't heard anything about it in about a month now.
Unfortunately the only way I can release the FPS sample project is if Fholm can create a sort of "stub" version of Bolt's DLLs (that is, it contains all of the classes for, say, BoltEntity, BoltHitbox, BoltHitboxBody, etc but none of the functionality), otherwise a bunch of script references will just get blown out and you're left with a ton of manual fixing.
[QUOTE=KillaMaaki;46508850]Unfortunately the only way I can release the FPS sample project is if Fholm can create a sort of "stub" version of Bolt's DLLs (that is, it contains all of the classes for, say, BoltEntity, BoltHitbox, BoltHitboxBody, etc but none of the functionality), otherwise a bunch of script references will just get blown out and you're left with a ton of manual fixing.[/QUOTE]
Would that still be a problem for people who have a BoltEngine license and a working/up to date copy or is it a matter of references that aren't there due to another issue?
If it's just a matter of "packaging up" the prefab and not having the rights to distribute everything, I'm sure everybody interested had the reasonable expectation that they needed a license to continue work on it. I'd imagine people would treat your project as an add-on, just like a DFGUI skin that is being sold rather than a complete thing that is ready to go.
[QUOTE=Velocet;46508887]Would that still be a problem for people who have a BoltEngine license and a working/up to date copy or is it a matter of references that aren't there due to another issue?
If it's just a matter of "packaging up" the prefab and not having the rights to distribute everything, I'm sure everybody interested had the reasonable expectation that they needed a license to continue work on it. I'd imagine people would treat your project as an add-on, just like a DFGUI skin that is being sold rather than a complete thing that is ready to go.[/QUOTE]
Yes, it is a problem. The problem is that, since the project wouldn't come with Bolt, you'd have to import Bolt after the fact. This is what breaks the script references, because Unity generates new asset IDs for the imported DLLs, so the old stored ID references don't work.
The idea behind having a sort of "dummy" DLL, however, would be that (hopefully) when you go to import Bolt, Unity sees the old DLL in place and just overwrites it with the new DLL without regenerating the asset IDs (updating the asset, rather than importing new ones)
[QUOTE=KillaMaaki;46508897]Yes, it is a problem. The problem is that, since the project wouldn't come with Bolt, you'd have to import Bolt after the fact. This is what breaks the script references, because Unity generates new asset IDs for the imported DLLs, so the old stored ID references don't work.
The idea behind having a sort of "dummy" DLL, however, would be that (hopefully) when you go to import Bolt, Unity sees the old DLL in place and just overwrites it with the new DLL without regenerating the asset IDs (updating the asset, rather than importing new ones)[/QUOTE]
Oh alright I understand, that makes sense. I'll see if I can talk to Fholm about it the next time he pops up on chat, that definitely sounds like a major issue that is barring a lot of users from working together on various projects. I hope you are still considering releasing it one day because it significantly lessens the amount of work we're looking at when creating a multiplayer title. On the other hand, I'd imagine that creators would love to create a lite version of their projects to sell on the asset store to receive some additional funding as well since the hard work is already complete.
Also are you taking applications for the test? You posted about it on the Bolt forums several weeks back and I'd love to check it out for myself.
[QUOTE=KillaMaaki;46508897]Yes, it is a problem. The problem is that, since the project wouldn't come with Bolt, you'd have to import Bolt after the fact. This is what breaks the script references, because Unity generates new asset IDs for the imported DLLs, so the old stored ID references don't work.
The idea behind having a sort of "dummy" DLL, however, would be that (hopefully) when you go to import Bolt, Unity sees the old DLL in place and just overwrites it with the new DLL without regenerating the asset IDs (updating the asset, rather than importing new ones)[/QUOTE]
You can always reverse engineer the bolt library easily (if it is written in C# that is)
[QUOTE=Fourier;46509551]You can always reverse engineer the bolt library easily (if it is written in C# that is)[/QUOTE]
Creating a dummy versions of the Bolt libraries is harder than it sounds.
[QUOTE=KillaMaaki;46510814]Creating a dummy versions of the Bolt libraries is harder than it sounds.[/QUOTE]
Well it does sounds easy but I am no expert in this.
Why don't you contact the Bolt developer?
[QUOTE=Fourier;46509551]You can always reverse engineer the bolt library easily (if it is written in C# that is)[/QUOTE]
It's open source, it's more an issue of licensing.
But yeah, talk to fholm.
[QUOTE=KillaMaaki;46510814]Creating a dummy versions of the Bolt libraries is harder than it sounds.[/QUOTE]
Even if you were to do it, it'd probably get broken in an update since it'd be unofficial. Also if I'm understanding correctly, this makes it nearly impossible for teams to work together when it comes to networking projects. It's something that needs to be included in Bolt for sure.
Grr, just discovered that BoltPhysicsHit.distance is returning unreliable values... or at least values I'm not expecting.
Gonna have to dig through the Bolt source code to see how he's calculating distance... something is not right here.
[IMG]http://i.imgur.com/rD1J7gV.gif[/IMG]
EDIT: Found it. Apparently Bolt does NOT like it when you scale any part of the hierarchy when hitboxes are involved.
[QUOTE=KillaMaaki;46514713]
EDIT: Found it. Apparently Bolt does NOT like it when you scale any part of the hierarchy when hitboxes are involved.[/QUOTE]
Now that just sucks, developer is being lazy
[QUOTE=Fourier;46518838]Now that just sucks, developer is being lazy[/QUOTE]
I assume it's got something to do with the matrix math that's going on, he's using the worldToLocalMatrix to transform the raycast into the hitbox's local space and then doing Bounds.IntersectRay. Something's going wrong in that process though because if i scale the root of my character skin by 0.85 it screws up the reported distance.
[QUOTE=KillaMaaki;46519043]I assume it's got something to do with the matrix math that's going on, he's using the worldToLocalMatrix to transform the raycast into the hitbox's local space and then doing Bounds.IntersectRay. Something's going wrong in that process though because if i scale the root of my character skin by 0.85 it screws up the reported distance.[/QUOTE]
Well I doubt he didn't noticed this.
But I also generally hate scalling things in unity because some things just break.., :(
Has anyone tried baking AO for an entire scene in Unity? Their built in SSAO sucks and I'd rather just bake it.
I'm able to bake AO for individual meshes in Blender, however, this isn't really accurate since in Blender I'm doing it one object at a time, therefore it doesn't really have a context of the rest of the scene where objects are occluding other objects.
I was debating creating the entire scene in Blender so that I can bake it all at once but that causes other issues in itself.
Ideas?
Sorry, you need to Log In to post a reply to this thread.
