GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited November 2009
I wish Pixel Mine would hurry up and update nFringe for the UDK. Having to write my US in Notepad++, compile it using the front end, and not being able to debug it, is very annoying.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited November 2009
nFringe is free? You just need to get Visual Studio 2008 Express (which is free).
The problem with nFringe is that until they update it to work with the UDK, you can't debug. You can configure it to start the UDK, and compile the scripts, but without debugging, you're missing a huge part of what makes nFringe so awesome: The ability to debug US in Visual Studio.
Updated the music. Got rid of the cello, to remove the bass. Also added a large amount of reverb, to pull the sound to the background. Hope I haven't gone backwards.
Much better. Only thing is, the stringed instrument gets a bit sombre at around 40 seconds and the piece stops feeling happy. Up to then, I would feel good about using this piece.
Next step: Make a HARDCORE OH SHIT THERE'S A VELOCIRAPTOR version for it to suddenly blend into when your cover's blown or you pounce a guy. The tune should be the same, though, so that it can blend in and out easily.
I still think it's a bit calm. What happens if you put in a bass line composed of quarter and eighth notes? Might give it a bit of the "drive" it seems to be lacking.
To be honest, I'd remove the strings holding up the back. It creates tension that spoils the airy nature of the song.
NotASenator on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited November 2009
So I was able to take that super-minimal UTGame zip that guy made and start on my RPG engine. So far I'm still going through the original UTGame source, figuring out the "rigging" that I need to port over, to get a complete game. There is quite a bit of good stuff in UTGame, you just need to separate it from the UT specific code.
What bothers me, is that so much of UTGame seems to be implemented natively. For instance, if you look at UTPlayerInput.uc, you'll notice it's a native class, which extends another native class, contains one native function and a cpptext block. Since, I believe, native classes are implemented by name, this makes it seem almost impossible to create your own named implementation of UTPlayerInput. You would need to extend it, to get the same level of functionality.
This bothers me a little bit, because it very heavily ties you to UTGame.
So I was able to take that super-minimal UTGame zip that guy made and start on my RPG engine. So far I'm still going through the original UTGame source, figuring out the "rigging" that I need to port over, to get a complete game. There is quite a bit of good stuff in UTGame, you just need to separate it from the UT specific code.
What bothers me, is that so much of UTGame seems to be implemented natively. For instance, if you look at UTPlayerInput.uc, you'll notice it's a native class, which extends another native class, contains one native function and a cpptext block. Since, I believe, native classes are implemented by name, this makes it seem almost impossible to create your own named implementation of UTPlayerInput. You would need to extend it, to get the same level of functionality.
This bothers me a little bit, because it very heavily ties you to UTGame.
This is basically, I think, what the Torque guy was getting at.
So I was able to take that super-minimal UTGame zip that guy made and start on my RPG engine. So far I'm still going through the original UTGame source, figuring out the "rigging" that I need to port over, to get a complete game. There is quite a bit of good stuff in UTGame, you just need to separate it from the UT specific code.
What bothers me, is that so much of UTGame seems to be implemented natively. For instance, if you look at UTPlayerInput.uc, you'll notice it's a native class, which extends another native class, contains one native function and a cpptext block. Since, I believe, native classes are implemented by name, this makes it seem almost impossible to create your own named implementation of UTPlayerInput. You would need to extend it, to get the same level of functionality.
This bothers me a little bit, because it very heavily ties you to UTGame.
This is basically, I think, what the Torque guy was getting at.
And just because I'm learning about this stuff and want to think I know what I'm talking about - These native classes reference DLL files which are done in C++ and unavailable to edit for us free UDK users, right?
I've got an idea, I tried it in L4D's sdk and I just quit in frustration.
Basically I want to make the alamo. And I want the alamo to be rushed by zombies. I guess in this SDK i can atleast make vehicles and whatnots and expand this into a techno madmaxian w/zombies in Texas.
It would be so easy if i could just import the area from google map into unrealed.
FingerSlut on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
So I was able to take that super-minimal UTGame zip that guy made and start on my RPG engine. So far I'm still going through the original UTGame source, figuring out the "rigging" that I need to port over, to get a complete game. There is quite a bit of good stuff in UTGame, you just need to separate it from the UT specific code.
What bothers me, is that so much of UTGame seems to be implemented natively. For instance, if you look at UTPlayerInput.uc, you'll notice it's a native class, which extends another native class, contains one native function and a cpptext block. Since, I believe, native classes are implemented by name, this makes it seem almost impossible to create your own named implementation of UTPlayerInput. You would need to extend it, to get the same level of functionality.
This bothers me a little bit, because it very heavily ties you to UTGame.
This is basically, I think, what the Torque guy was getting at.
And just because I'm learning about this stuff and want to think I know what I'm talking about - These native classes reference DLL files which are done in C++ and unavailable to edit for us free UDK users, right?
In the case of UTGame, the code is actually compiled in to UDK.exe, but yes, the idea is the same.
So I was able to take that super-minimal UTGame zip that guy made and start on my RPG engine. So far I'm still going through the original UTGame source, figuring out the "rigging" that I need to port over, to get a complete game. There is quite a bit of good stuff in UTGame, you just need to separate it from the UT specific code.
What bothers me, is that so much of UTGame seems to be implemented natively. For instance, if you look at UTPlayerInput.uc, you'll notice it's a native class, which extends another native class, contains one native function and a cpptext block. Since, I believe, native classes are implemented by name, this makes it seem almost impossible to create your own named implementation of UTPlayerInput. You would need to extend it, to get the same level of functionality.
This bothers me a little bit, because it very heavily ties you to UTGame.
This is basically, I think, what the Torque guy was getting at.
And just because I'm learning about this stuff and want to think I know what I'm talking about - These native classes reference DLL files which are done in C++ and unavailable to edit for us free UDK users, right?
This is correct.
There are, of course, 3D engines of varying quality out there that give you access to source code if you want to mess around with that stuff.
So, my schedule is silly, but what it boils down to is that as soon as I'm done with my college semester, I'm going to be getting about half as many hours at work as well(which I want)
So I was able to take that super-minimal UTGame zip that guy made and start on my RPG engine. So far I'm still going through the original UTGame source, figuring out the "rigging" that I need to port over, to get a complete game. There is quite a bit of good stuff in UTGame, you just need to separate it from the UT specific code.
What bothers me, is that so much of UTGame seems to be implemented natively. For instance, if you look at UTPlayerInput.uc, you'll notice it's a native class, which extends another native class, contains one native function and a cpptext block. Since, I believe, native classes are implemented by name, this makes it seem almost impossible to create your own named implementation of UTPlayerInput. You would need to extend it, to get the same level of functionality.
This bothers me a little bit, because it very heavily ties you to UTGame.
This is basically, I think, what the Torque guy was getting at.
And just because I'm learning about this stuff and want to think I know what I'm talking about - These native classes reference DLL files which are done in C++ and unavailable to edit for us free UDK users, right?
This is correct.
There are, of course, 3D engines of varying quality out there that give you access to source code if you want to mess around with that stuff.
I dunno.. but the more I poke around the UnrealScript source, the more I get the impression you don't need source access to make whatever you want with UDK. I would like a lot more control over the main game loop but as it is, its workable for pretty much anything. I'm actually surprised at how well UT3 runs considering how much of the game is in a scripting language and not C
edit: I also love how every time I check the UDK Programming documentation section, there is 2-3 new articles at least
Sakeido on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
So I was able to take that super-minimal UTGame zip that guy made and start on my RPG engine. So far I'm still going through the original UTGame source, figuring out the "rigging" that I need to port over, to get a complete game. There is quite a bit of good stuff in UTGame, you just need to separate it from the UT specific code.
What bothers me, is that so much of UTGame seems to be implemented natively. For instance, if you look at UTPlayerInput.uc, you'll notice it's a native class, which extends another native class, contains one native function and a cpptext block. Since, I believe, native classes are implemented by name, this makes it seem almost impossible to create your own named implementation of UTPlayerInput. You would need to extend it, to get the same level of functionality.
This bothers me a little bit, because it very heavily ties you to UTGame.
This is basically, I think, what the Torque guy was getting at.
And just because I'm learning about this stuff and want to think I know what I'm talking about - These native classes reference DLL files which are done in C++ and unavailable to edit for us free UDK users, right?
This is correct.
There are, of course, 3D engines of varying quality out there that give you access to source code if you want to mess around with that stuff.
I dunno.. but the more I poke around the UnrealScript source, the more I get the impression you don't need source access to make whatever you want with UDK. I would like a lot more control over the main game loop but as it is, its workable for pretty much anything. I'm actually surprised at how well UT3 runs considering how much of the game is in a scripting language and not C
edit: I also love how every time I check the UDK Programming documentation section, there is 2-3 new articles at least
The issue is, that to do anything substantial, you will need to extend and use UTGame, because so much of it is native. Even Whizzle, which is not a first person game at all, packages and references UTGame heavily. This means you end up fighting the UTGame system to make whatever game it is you want. For instance, take a look at UTPawn some time. There is a ton of UT specific stuff in there that I couldn't care less about for an RPG, or a puzzle game. It's a terrible amount of bloat.
Yet, you can't re-implement a large portion of those classes because they are native.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited November 2009
You know, after looking at the Whizzle source, I am actually a little more excited. They actually use very, very little UTGame functionality, all things considered. They actually extend a lot of the core Engine classes, like PlayerInput and GameInfo. They completely skipped the GameFramework and UTGame stuff, and just extended raw engine classes.
I feel much better now, and this is much more promising.
Thanks Gnome and NotACrook
Another newbie programming question:
Simulated Functions are more for Network related things? I love/hate getting into things like that because I have a zillion questions all while processing a zillion things at the same time.
At least I got the camera to work in Editor and in Game. Yay
I dunno.. but the more I poke around the UnrealScript source, the more I get the impression you don't need source access to make whatever you want with UDK. I would like a lot more control over the main game loop but as it is, its workable for pretty much anything. I'm actually surprised at how well UT3 runs considering how much of the game is in a scripting language and not C
edit: I also love how every time I check the UDK Programming documentation section, there is 2-3 new articles at least
The issue is, that to do anything substantial, you will need to extend and use UTGame, because so much of it is native. Even Whizzle, which is not a first person game at all, packages and references UTGame heavily. This means you end up fighting the UTGame system to make whatever game it is you want. For instance, take a look at UTPawn some time. There is a ton of UT specific stuff in there that I couldn't care less about for an RPG, or a puzzle game. It's a terrible amount of bloat.
Yet, you can't re-implement a large portion of those classes because they are native.
It could be more elegant sure, but from what I saw you could easily delete huge portions of those files or re-purpose some of the functions to do something else. There is another set of UC files in a different directory I haven't looked at that supposedly have a more bare bones set of functions, and the UTGame is extending those.. I know there is one for Pawn at least
I dunno.. but the more I poke around the UnrealScript source, the more I get the impression you don't need source access to make whatever you want with UDK. I would like a lot more control over the main game loop but as it is, its workable for pretty much anything. I'm actually surprised at how well UT3 runs considering how much of the game is in a scripting language and not C
edit: I also love how every time I check the UDK Programming documentation section, there is 2-3 new articles at least
The issue is, that to do anything substantial, you will need to extend and use UTGame, because so much of it is native. Even Whizzle, which is not a first person game at all, packages and references UTGame heavily. This means you end up fighting the UTGame system to make whatever game it is you want. For instance, take a look at UTPawn some time. There is a ton of UT specific stuff in there that I couldn't care less about for an RPG, or a puzzle game. It's a terrible amount of bloat.
Yet, you can't re-implement a large portion of those classes because they are native.
It could be more elegant sure, but from what I saw you could easily delete huge portions of those files or re-purpose some of the functions to do something else. There is another set of UC files in a different directory I haven't looked at that supposedly have a more bare bones set of functions, and the UTGame is extending those.. I know there is one for Pawn at least
That base set of functions you are talking about is the 'Engine' package. If you look in Development/Src/Engine, you'll see it. That is the absolute bare minimum set of functionality for the engine to work. If you look at the Whizzle source (which I highly recommend, as it's a great example of how to do a complete game in the UDK), you'll see most of their classes extend from classes in the Engine package.
All of my work so far has been extending dev/src/engine. I fall back on UTGame components for testing stuff from time to time, but I found that I am happier and less confused building up from scratch instead of trying to decode how UTGame is doing it.
NotASenator on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
All of my work so far has been extending dev/src/engine. I fall back on UTGame components for testing stuff from time to time, but I found that I am happier and less confused building up from scratch instead of trying to decode how UTGame is doing it.
Agreed. Which is why I am glad I looked at Whizzle, because it gave me the confidence it could be done.
I am excited to go home tonight and use the wildicv tutorials to setup nFringe and get to coding. My goal is to have an NPC actor and a player actor able to make basic combat attacks against each other very soon.
All of my work so far has been extending dev/src/engine. I fall back on UTGame components for testing stuff from time to time, but I found that I am happier and less confused building up from scratch instead of trying to decode how UTGame is doing it.
Agreed. Which is why I am glad I looked at Whizzle, because it gave me the confidence it could be done.
I am excited to go home tonight and use the wildicv tutorials to setup nFringe and get to coding. My goal is to have an NPC actor and a player actor able to make basic combat attacks against each other very soon.
Still no debugging, right?
NotASenator on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited November 2009
Nope, still no debugging, but you can use 'log() and the development console to do 1985 style PRINT debugging.
When I added my scripts and changed some things and ran the UDK editor I would get a little cmd prompt type thing that would go through my scripts and validate em - at first it found a few errors but they were resolved after a few minutes. I opened up the Unreal Frontend and ran the 'Make' deal, but it was doing the packages, not the scripts.
How can I get that script checker thing to run again?
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited November 2009
If your scripts are part of the package that is set as the "EditorPackage" in one of the ini files, it will re-build them every time they change and you start the editor. If you're using nFringe, you can also force them to build from inside Visual Studio with the basic "Build Solution" menu option.
Posts
Well, I'm not a programmer per say, but hey!
Mvrck - That is a fantastic suggestion! And thanks for humoring me
Spent some time reading on the difference of native and simulated functions.
Looooooooooooooooooooooooooooooooooooooooooottts of information to digest.
Also, any -free- or cheap IDE one can use? nFringe is out of my league.
The problem with nFringe is that until they update it to work with the UDK, you can't debug. You can configure it to start the UDK, and compile the scripts, but without debugging, you're missing a huge part of what makes nFringe so awesome: The ability to debug US in Visual Studio.
I think the game would be even better if it was set in 1962. Who doesn't love cigarette chomping journalists?
i think you might be following the wrong game
http://eyelove.posterous.com/happy-office-3
Next step: Make a HARDCORE OH SHIT THERE'S A VELOCIRAPTOR version for it to suddenly blend into when your cover's blown or you pounce a guy. The tune should be the same, though, so that it can blend in and out easily.
What bothers me, is that so much of UTGame seems to be implemented natively. For instance, if you look at UTPlayerInput.uc, you'll notice it's a native class, which extends another native class, contains one native function and a cpptext block. Since, I believe, native classes are implemented by name, this makes it seem almost impossible to create your own named implementation of UTPlayerInput. You would need to extend it, to get the same level of functionality.
This bothers me a little bit, because it very heavily ties you to UTGame.
This is basically, I think, what the Torque guy was getting at.
And just because I'm learning about this stuff and want to think I know what I'm talking about - These native classes reference DLL files which are done in C++ and unavailable to edit for us free UDK users, right?
Basically I want to make the alamo. And I want the alamo to be rushed by zombies. I guess in this SDK i can atleast make vehicles and whatnots and expand this into a techno madmaxian w/zombies in Texas.
It would be so easy if i could just import the area from google map into unrealed.
In the case of UTGame, the code is actually compiled in to UDK.exe, but yes, the idea is the same.
This is correct.
There are, of course, 3D engines of varying quality out there that give you access to source code if you want to mess around with that stuff.
I'll use that time usefully, damnit :P
3ds friend code: 2981-6032-4118
I dunno.. but the more I poke around the UnrealScript source, the more I get the impression you don't need source access to make whatever you want with UDK. I would like a lot more control over the main game loop but as it is, its workable for pretty much anything. I'm actually surprised at how well UT3 runs considering how much of the game is in a scripting language and not C
edit: I also love how every time I check the UDK Programming documentation section, there is 2-3 new articles at least
The issue is, that to do anything substantial, you will need to extend and use UTGame, because so much of it is native. Even Whizzle, which is not a first person game at all, packages and references UTGame heavily. This means you end up fighting the UTGame system to make whatever game it is you want. For instance, take a look at UTPawn some time. There is a ton of UT specific stuff in there that I couldn't care less about for an RPG, or a puzzle game. It's a terrible amount of bloat.
Yet, you can't re-implement a large portion of those classes because they are native.
I feel much better now, and this is much more promising.
Another newbie programming question:
Simulated Functions are more for Network related things? I love/hate getting into things like that because I have a zillion questions all while processing a zillion things at the same time.
At least I got the camera to work in Editor and in Game. Yay
It could be more elegant sure, but from what I saw you could easily delete huge portions of those files or re-purpose some of the functions to do something else. There is another set of UC files in a different directory I haven't looked at that supposedly have a more bare bones set of functions, and the UTGame is extending those.. I know there is one for Pawn at least
Mastering Unreal Script
part 1 http://udn.epicgames.com/Three/MasteringUnrealScriptBaptismByFire.html
part 2 http://udn.epicgames.com/Three/MasteringUnrealScriptClasses.html
part 3 http://udn.epicgames.com/Three/MasteringUnrealScriptFunctions.html
things I wish Unreal Ed had: CUDA support for lightmass baking
I'd prefer DirectCompute or OpenCL support for that, so it worked on ATI cards as well :P
That base set of functions you are talking about is the 'Engine' package. If you look in Development/Src/Engine, you'll see it. That is the absolute bare minimum set of functionality for the engine to work. If you look at the Whizzle source (which I highly recommend, as it's a great example of how to do a complete game in the UDK), you'll see most of their classes extend from classes in the Engine package.
Agreed. Which is why I am glad I looked at Whizzle, because it gave me the confidence it could be done.
I am excited to go home tonight and use the wildicv tutorials to setup nFringe and get to coding. My goal is to have an NPC actor and a player actor able to make basic combat attacks against each other very soon.
Still no debugging, right?
When I added my scripts and changed some things and ran the UDK editor I would get a little cmd prompt type thing that would go through my scripts and validate em - at first it found a few errors but they were resolved after a few minutes. I opened up the Unreal Frontend and ran the 'Make' deal, but it was doing the packages, not the scripts.
How can I get that script checker thing to run again?