Announcement

Collapse
No announcement yet.

Unofficial UDK Wiki

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Unofficial UDK Wiki

    Hello,

    I had a question about the Textual information of the UDN website content for Unreal Engine 3:

    I try to build a unofficial UDK Wiki at Wikia and i wanna use some informations from UDN-Unreal Engine 3.
    That exactly mean copy paste some massive amount of text, reformat it if necessary and bring it up to date as much as I can.
    This Wiki is more for me to learn more about Unreal Engine 3 and to having a centralized reference and less for making it public, but it is still a public Wiki and i plan to allow anybody, that is interested, to help me with it.

    I am interested in textual informations. If pictures are needed i made them by my self.
    I am not interested to making money in any kind.

    My main goal is it to collect anything i can find about Unreal Engine 3 in the WWW and write/copy it in this Wiki.

    I read a bit through the licence page here:

    Quote:
    "Intellectual Property Rights
    You are permitted to use the Website for your personal, non-commercial use only or legitimate business purposes related to your role as a current or prospective customer of Epic. Except as provided below, you must not copy, modify, create derivative works of, publicly display, publicly perform, republish, or transmit any of the material on our site, or delete, or alter any copyright, trademark, or other proprietary rights notices from copies of materials from the Website. However, if you are otherwise in compliance with these Terms, you are permitted to use, elsewhere and on other websites, an unaltered copy of portions of the content that is publicly available on the Website for the limited, non-commercial purpose of discussing such content."

    My english is not perfect especially if its goes about licence and law stuff. But if i read correctly i can use the, in the UDN stored, information for non-commercial use.

    So, please give me some advice about this topic or can i cancel my project before it even really start?
    Or is this idea totaly stupid? ^^
    Or is ther already an Unofficial UDK Wiki?

    Thanks in advance

    #2
    Hey that is a cool idea !
    I don't think that you need your english to be perfect.

    I think that from my expirience we should divide into 3 sections , Level design, Animation, And Programming
    Don't include outdated stuff like Terrain, and other un usefule stuff.

    Comment


      #3
      Hello,
      and thank you for your answer. :]

      I really taught I am an idiot and wasting time^_^, but as long as i can use it i am happy, but i fear some licensing conflicts in the future. :[
      I always give a source link from where i got this information to at least respect the authors of that knowledge and avoiding licence conflicts.

      About the information structure of this Wiki:
      This is how it looks at the moment:

      - Unreal Engine 3
      - Basics
      - Content creation
      - Level-Design
      - Programming (but i am not a programmer and cannot really maintain this category, I just copy paste what the UDN says about )
      - Resources

      - 3ds Max
      - (no subcategories and content at the moment)

      - Photoshop
      - (also no subcategories and content at the moment)

      But see for yourself, IF you like!

      The last 2 main categories are exist because i work with these Programms. There could also exist a Maya and Gimp section but for me it would be time wasting and overwhelmed to work with more than one 3D/Picture manipulator Programm at the same time.

      And without copy pasting stuff from anywhere, it would take years to type anything in and as long as I am alone here it would be take a lot of time to correcting/completing all stuff inside it I try to collect. So, in the moment i copy paste all i find to build up a simple structure and if i find out what is wrong or incomplete I try to correct/complete what i can. I also new to Wikia and need to learn how to maintain a Wiki. ^_^ But as far as i see, at the moment, is much easier to maintain a Wiki than building a Webpage by hand or collecting this knowledge in a folder based structure filled with txt/doc files ;]

      And like i said: its public, so anybody can join if he desire so. I really would appreciate this! Nobody needs to stay forever or would have any liabilities, i just doing this because i had fun with it.

      And sorry about the selfish name of the Wiki but there is already and Wiki called "UDK Wiki", but it has no content and its hard to find via google because the name is not really unique. The author says in a note that Wikia sucks and that it is not listed in the internal Wikia search.
      And i say: "Who cares if it does, the important thing is that major search engines can find it, and they do find it."

      ****, i think i write to much ^_^.

      But one last question: Is there are a UDK Wiki out there? I can't find anything big!
      I don't wanna wast time by doing the same that already being done by others. I came fresh from source engine (Source Engine sucks!^^) and there sooo many Wikis forums and what ever out there that try to be the best and coolest and in my opinion its a wast of time by compete each other.
      And i absolutely not understand why there is no real free/unofficial UDK Wiki about the beautiful Unreal Engine 3 out there. Its like the source engine: dozent of sites and stuff that provide little pieces of knowledge. I just try to create a place of centralized knowledge where people can join and share its knowledge(IF they want) instead of spreading it over the world and competing each others knowlege bases!


      SO, thanks for wasting your time by reading this

      Comment


        #4
        many sites like this have come and gone, some good, some bad.
        1 i dont remember the name of was pretty good and had many contributions from community members (when it was active), of course its dead and gone now.

        this one is always there
        http://wiki.beyondunreal.com/

        btw you are very welcome to include any of my tutorials/code/ect if you want

        Comment


          #5
          Hello,

          thanks for the answer and i will add your tutorials. I think i add some links that lead directly to them instead of copy pasting it and I link to your YouTube channel and stuff.
          I am not good in coding at all, all i can do is some batch scripting and the basics of c++. I am more focused on textures, materials, level building, lighting and models design.
          SO, thanks!

          I found the Beyondunreal Wiki before, hmmm, but i am not sure what i should think about it, i don't wanna compete with it but i can't anyway, i think.^^ Maybe i try joining them if my work grows over my head.
          But i have to say i don't like the graphical style of the Beyondunreal Wiki, i don't like bright colors, i like more dark and warm colors, but this is more a personal opinion, i think.

          But for now I try creating my own basic category that cover all features of the UDK. This will help me growing my knowledge about all available functions of UDK. I am not that uninformed about the UnrealEd but there is soo much more to learn and understand and instead of making my own personal notices I make them public and this Wiki kinda database is a great way of doing this, thats all.

          Comment


            #6
            If you try and cover every aspect of UDK in your Wiki you'll probably fail. Why? Because the danger of planning a Wiki that's all things to all people, is that it actually helps no one. Look at the Beyond Wiki pages or similar wikis. A huge number of the properties pages are auto-generated, so they lack detail, and therefore have little useful practical information. Whereas game devs can often learn more by trawling through the declaration sections of the classes and reading Epic's comments instead.

            So my advice is to pick a specialization for your Wiki and go from there. For example: A significant number of game developers start out creating games using the UTGame classes. So why not have a Wiki that lists the Top-100 most useful switches or variables... Examples :-


            Enable / Disable Player Jumping.
            Enable / Disable Player Crouching.
            Increase / Decrease Pawn Speed.
            Increase the amount of time Dead-Pawn bodies stay visible.
            Change the hill gradient / slope Pawns can walk on.
            Stop Vehicles disappearing and resetting to base seconds after a player hops out.
            Stop aircraft auto-landing / falling to ground in Gravity Volumes...


            Another area that could benefit from a Wiki is physics, especially getting the right behavior from Kactors so that they can properly interact with a host of different actors. This boils down to understanding events and which ones fire correctly based on setting different properties including bNotifyRigidBody & bNoEncroachCheck + others, but the whole area is badly documented. So a Wiki based checklist could help...

            Overall, the documentation is my least favourite aspect of UDK. Its a barrier to making progress and makes Unity appear far more attractive, despite UDK having richer visuals and better physics IMHO. I suspect a lot of people like me give up on the documentation after a point and just try things, because its faster and it delivers immediate results.

            Comment


              #7
              Hello,
              Thanks for the answer!

              Originally posted by frankit View Post
              If you try and cover every aspect of UDK in your Wiki you'll probably fail.
              You are right. To cover all would be nearly impossible, especially for one inexperienced person like me. But I want have at lest a reference to important features I use and I don't want give up in the first 2 days. ;]
              And like I said before, this Wiki is, at the moment, more for me and less for others. But if people want to look through it/help completing or correcting it I have no problem with that.
              And it does not look like people have interest because, like you said, UDK is a huge topic and its hard to cover all. But source engine its a huge topic too and this **** engine is much more chaotic and hard to manage, I waste nearly 8 years of my life trying to understand it (my focus was texture creation and level design). Its full of bugs and valve has only money and stealing community ideas in mind and there is still a lot of interest in it, what I absolutely not understand. I could talk more about this topic but this is not the right place I think.^^

              Originally posted by frankit View Post
              My advice is to pick a specialization for your Wiki and go from there.
              Good idea I will keep this in mind. And try to pick something I am good in.

              Originally posted by frankit View Post
              A lot of game developers start out creating games from the UTGame classes.
              THIS is one of my biggest problems I wannabe a content creator and have no idea how to code for unreal, and I am not that interested in it, it confuses me lot and I like more create thing I can see. Maybe I could describe me as an artist. So I try to focus on materials, level design and model design, put stuff out in the community and maybe I could work with other people together(But i have not much to give in the moment :[ ). I can't do all alone especially coding takes a lot of time to learn and dont really want do coding. But I need to start some where and people I know have no interest in Unreal Engine development, they just want to play games but I want to do more than just playing!


              Originally posted by frankit View Post
              Another area that baffles devs is physics, especially getting the right behaviour out of KActors so that they interact properly with a host of different actors. This boils down to understanding events and which ones fire correctly, but the whole area is badly under-documented.
              I see that! And this is some reason why I had this Wiki idea. I work a lot with "Apex destructible Assets" (ADA's) and they are kinda strange things/objects.
              Its hard to describe my experience with them but I try to be short:
              They look good and its kinda impressive what I could create with them in such a short time (1-2 weeks , 4-10h a day - feel free to look at it - DL if the quality is bad or the video hangs to much) and it its just looks awesome to see structures collapse "almost" realistic.
              But the lighting behave bad; either I hand environmental lighting what gave me strange glitches or I had dynamic light what suck up A LOT of performance and had NO environmental lighting at all. I don't find out how the use the benefits of both lighting systems! I think I am still to inexperienced and that I tempt my self to using them was kinda wrong, because there is "almost no" references out there for how using them and nearly no interest in using them with Unreal Engine 3, afaik.

              If there people out there that want to use ADA's too I am very interested in this topic. OR, If these ADA's just in-performant useless bull5hit than please tell me and I stop trying to create a almost fully destructible environment :\

              Comment


                #8
                ADA is ok, still chunky looking, but way better than internal fractured meshes. However Apex is not sufficient if your environment is 'moving'. If so then you're into some serious programming voodoo, although Rama and others have offered some possible solutions...

                For a fully destructible high-performance environment consider a mixture of fractured, Apex and packed Interpactors, the latter having physics set to RigidBody at the time of the explosion. This works because packed RigidBodies repel each other by default using UDK's physics engine. You can also secretly pack smaller chunks of varying sizes inside the larger chunks to create realistic explosions along with particle FX. This can be very high-throughput too with thousands of interpactors / movers 'exploding' at the same time!

                The sample video looks fine, the bricks and wood help cover up the usual chunkiness of Apex / UDK Fractured meshes. But the destroyed ceilings look the best with the 'steel' structural-wires protruding out of the ashes of the concrete, I like it! But the lifetime of the chunks is still far too short and unrealistic. One of the advantages of making an interpactor / mover type destructible environment is that you control all the destructive aspects precisely... Overall, I don't know why game / physics engines have such unrealistic default destruction settings. Its as bad as dead bodies disappearing near instantly... Once upon a time GPU limitations + memory were the probable reason but not any more!

                Comment


                  #9
                  oh man, I feel really inexperienced. ^_^

                  (BTW.: We maybe should make an separate thread about ADA's so other people can find it better)


                  Originally posted by frankit View Post
                  ADA is ok, still chunky looking, but way better than internal fractured meshes. However its not sufficient if your environment moves. Then you're into some serious programming voodoo.
                  I don't really like fractured meshes, they good but have big limitations, afaik, if I try to set the chunk size to a random scale of, idk, 50% - 60% of the original size and make a cut with laser the sliced off piece just disappear, what just look unrealistic. To give you an example just look here and wait until I start slicing the first concrete block. The big piece I cut off would disappear if I set the random chuck size.




                  I think there is no need that things move. If you mean a train or something than can be destroyed if it rolls around.
                  (Hmm instead moving the ADA's the environment could be "moved" around like these train-level of UT2004 I cant remember the name, I think its kinda moving texture effect or something, but anyway, I don't plan to make a train or something big that moves)

                  But a question about moving, I would like to create a ADA crate (just an example it could be a rock or something else) that can be thrown around with the physgun and brake into parts if crashing against something, but I am not a coding voodoo priest ;]. So, is it possible to make ADA's to behave like Interpactors without serious Coding Voodoo? I don't find out how to interact with ADA's with the pysgun because the is no deep documentation about this ADA topic :\

                  Originally posted by frankit View Post
                  But for you a hybrid solution is also a possibility to get fully destructible environments i.e. a mixture of fractured, Apex and packed Interpactors, the latter with physics changed to RigidBody at the time of explosion.
                  what is a "packed InterpActor"?

                  And Can I handle this kinda changes with kismet?

                  I have to say I am not really familiar with kismet and I just can do basic stuff, but kismet is something I am really interested in, I love the idea behind visual scripting, It makes kinda fun and I see better how things are connected/talk to each others.
                  (**** I really need to learn more about kismet, afaik it is really powerful and I want to be able to use its massive power :] BUT there comes the problem with the less documentation again, only the basics are covered in the UDN, I just look for testing )

                  Originally posted by frankit View Post
                  This works because packed RigidBodies will repel each other by default using UDK's physics engine. You can also secretly pack smaller chunks of varying sizes inside the larger chunks to create realistic explosions. This is high throughput too, you can do this with thousands of interpactors / movers at the same time and UDK will handle all of them fine...
                  I am not really sure what you mean exactly, sorry

                  Originally posted by frankit View Post
                  The sample video looks fine, the bricks and wood help cover up the usual chunkiness of Apex / UDK Fractured meshes.
                  Thanks, and all you see is made out of ADA's because I am really fascinated in them and destructible environment is the newest and hottest **** ;]
                  ANd thanks that you not blame me about my strange music favour, I use it to cover that the destruction has absolutely no sound at all ;]

                  Originally posted by frankit View Post
                  But the lifetime of the chunks is far too short and unrealistic.
                  Absolutely, BUT this wood stuff is experimental and made out of to much pieces and its eat up my GPU/CPU for breakfast ;]
                  that mean I got massive frame drops if I destroy allot at once. Even without dynamic lighting.


                  Originally posted by frankit View Post
                  I don't why game / physics engines have such unrealistic default destruction settings. Its as bad as dead bodies disappearing instantly...
                  hmm maybe developers are just to lazy to make it behave correct AND with good performance, idk. However, the standard setting of an ADA are just bull**** and ridiculous. (one shot and the whole piece collapse :\)

                  And there comes the next big problem. The bugged Impact Resistance parameter of an ADA make them nearly worthless, afaik. Let my try to draw a picture in your mind:
                  I have a floor made out of ADA's (concrete), like in my little house, and if bigger pieces fall onto this floor they break it and itself a bit, good yeah. BUT, IF they break they create pieces that cause the fallen down object to move a tiny bit what cause damage to the floor again and it breaks again ..this cause an almost endless loop of destruction what cause a massive frame drop.
                  (Hmm did you think I could prevent this behaviour with disabling the "accumulate damage" flag?)


                  all this strange stuff drive me kinda crazy and without a real documentation about I can just post stupid questions in a forum and bother other people with this basic problems

                  Comment


                    #10
                    Originally posted by Caeon View Post
                    oh man, I feel really inexperienced
                    Just trying ideas out / experimenting helps with learning UDK. Don't sweat being experienced / inexperienced just try and have fun with the product... Remember every single one of us game devs is inexperienced versus the talents @ Epic...

                    Originally posted by Caeon View Post
                    I think there is no need that things move. If you mean a train or something than can be destroyed if it rolls around.
                    I was thinking of Spacebased structures from space-stations to barge ships etc... Or underwater worlds with moving structures etc.

                    Originally posted by Caeon View Post
                    But a question about moving, I would like to create a ADA crate (just an example it could be a rock or something else) that can be thrown around with the physgun and brake into parts if crashing against something
                    That's exactly what you cannot do with Apex by default. But Rama and others have written tutorials about how-to merge Apex and a Kactor to create an ApexKactor etc, but it requires code, Kismet won't help there.

                    Originally posted by Caeon View Post
                    what is a "packed InterpActor"?
                    Its just a technique. A large rock Mover / Interpactor can be animated and moved as a single piece, but actually be comprised of tens / hundreds / thousands of smaller interpactor rocks. You can then change the physics of the Movers using Kismet -> SetPhysics -> Phys_RigidBody. When you do the rocks will take on different properties and repel (push each other away at speed). This creates an explosive type effect... Try it out, go experiment...

                    Originally posted by Caeon View Post
                    And Can I handle this kinda changes with kismet?
                    Kismet has much more potential than many devs realize. Check out Henrik's tutorials for starters. But basically yes you can do a lot with it, and all the core switches and properties and variables in unrealscript can be changed directly from within Kismet using Get / Modify Property... I hinted at some of these in the post about Top-100 switches and variables... UDN docs on Kismet are poor. Its better to experiment with each node yourself and read past posts about each Node that you're having problems with... But remember this: there's only about 30 nodes that are key, so learn those well...

                    Originally posted by Caeon View Post
                    (Hmm did you think I could prevent this behaviour with disabling the "accumulate damage" flag?)
                    Can't say offhand. I figure stuff out by jumping in and trying it, and then keeping a detailed log of what works and what doesn't, so I don't redo everything over and over. What I dislike about Apex is the different versions and different results in different UDK builds, plus the crashes and bugs (search past posts). That's why I say a hybrid solution is best for me i.e. mix particle effects, fractured meshes (where they are less likely to look bad), ADA's, Interpactors w/ RigidBody physics set... Then blend them all together into a single FX effect that at a minimum is passable, and a maximum looks impressive...

                    Comment


                      #11
                      I edited that above post a lot afterwards sorry. I reply to posts while waiting for builds to finish.

                      Comment


                        #12
                        Originally posted by frankit View Post
                        Just trying ideas out / experimenting helps with learning UDK. Don't sweat being experienced / inexperienced just try and have fun with the product... Remember every single one of us game devs is inexperienced versus the talents @ Epic...
                        Thank you

                        Originally posted by frankit View Post
                        I was thinking of Spacebased structures from space-stations to barge ships etc... Or underwater worlds with moving structures etc.
                        OK, that includes buildings and parts of it right? I try to create a set of modular pieces that can be used to build any kind of structures.
                        Houses, Factory halls, Storage halls and so one. Maybe this is a bit big for me but I try and it will help to understand more about UDK.
                        and these standard staticMeshes are kinda boring. And, I maniac jump right into APAX physics without having an idea how complicated this topic can be
                        (if this relay works I publish this I think, but this takes some time I don't want publish unfinished buggy stuff)

                        Originally posted by frankit View Post
                        But Rama and others have written tutorials about how-to merge Apex and a Kactor to create an ApexKactor etc, but it requires code, Kismet won't help there.
                        I am really kinda feared about coding. Did you think I can just copy/paste the new class in my UDK and can than concentrate on the properties of this new stuff or did I had to do some serious coding stuff. I mean change some name inside the code I can manage, I think. But before I really start coding I should learn c++ before and this would take some time.
                        Sorry if this sound lazy but coding is often to complicated for me so I like to use prefab code and use the resulting new abilities. AND a friend of mine waits to buy a new PC and he maybe helps me with UDK coding. So I wait for him.

                        Originally posted by frankit View Post
                        Its just a technique. A large rock Mover / Interpactor can be animated and moved as a single piece, but actually be comprised of tens / hundreds / thousands of smaller interpactor rocks. You can then change the physics of the Movers using Kismet -> SetPhysics -> Phys_RigidBody. When you do the rocks will take on different properties and repel (push each other away at speed). This creates an explosive type effect... Try it out, go experiment...
                        So, this packed InterpActor stuff sound interesting. How do I create one?
                        Did I need to create a new class that can handle a ADA's as InterpActor, RigidBody or KActor to make it throwable and stuff? And As soon as it takes a specific amount of damage it brakes into single ADA_InterpActor's that also break in a normal ADA behaviours way?

                        How do I put more than one ADA in these class at same time? To make wall pieces that contain pillars, wood structures, isolation, cables, pipes and stuff. i.e to separate the floors, walls or something else from a house, from each other.

                        BTW.:
                        Can I solve the "my whole house can stay on a little piece of structure" Problem with these technique?
                        I.e.: the whole house can stay on a singe pillar and wont collapse like it in reality do, because it is a extended structure and I build all parts of the building out of modular reusable pieces and "glue" them with and space of 0, between each object, together. I find out that let them overlapping too much produces strange "pop out" behaviours if I shot on the connection point

                        Originally posted by frankit View Post
                        I hinted at some of these in the post about Top-100 switches and variables... UDN docs on Kismet are poor. Its better to experiment with each node yourself and read past posts about each Node that you're having problems with... But remember this: there's only about 30 nodes that are key, so learn those well...
                        Man you are should write a Wiki, LOL. However, I should spend some time to read in this forum. I Now have some good key Words.

                        Originally posted by frankit View Post
                        Can't say offhand. I figure stuff out by jumping in and trying it, and then keeping a detailed log of what works and what doesn't, so I don't redo everything over and over.
                        hmm I maybe try to protocol my experience in my little Wiki. But as longer as I think about this Wiki as more stupid the idea sound in my head :\

                        Originally posted by frankit View Post
                        What I dislike about Apex is the different versions and different results in different UDK builds, plus the crashes and bugs (search past posts).
                        Yeah, exactly, especially for newbies like me. But I made them work in its basic style and kinda proud of it and I am happy that other people still work with the UDk instead of jumping on the UE4 train.

                        Originally posted by frankit View Post
                        I edited that above post a lot afterwards sorry. I reply to posts while waiting for builds to finish.
                        No problem.


                        That pretty heavy stuff you tell me here I need to experiment and read a lot.
                        I am actually experiment only with the ADA's and its properties it self.


                        Do you know, btw, how to use swarm to bundle the power of multiple CPU's(a swarm farm) to process one project build. I have 5 old PCs here and I thought I could use them to speed up the process. The UDN is also worthless about this topic :\


                        sorry if I am ask so much questions but I am kinda tired and to lazy to make expensive searches.
                        I spend a lot of time in this Wiki stuff to use it as my personal protocol or what ever.

                        BTW.: The spelling of the words I use here is powered my notepad++ and its new spelling correction, without it, it would be very worse. Unfortunately he don't correcting my bad syntax/grammar.

                        So thanks again for helping me out and putting me on the right way, and wasting your time with me

                        Comment


                          #13
                          Don't learn C++ its overkill. You'd have to get your head around pointers, memory management and other highly-complex structures, many of which aren't in unrealscript. It would be completely unnecessary learning at this stage unless you have access to UE4. But if you're going to go down that rabbit hole anyway, then focus instead on learning C# or JavaScript which will be much more helpful and will ready you for learning Unity later if you choose.... C++ is like learning the guitar, it takes years to master and you have to learn everything 3 times. Whereas JS or C# is like learning the piano, its far more logical and easier to get to grips with, and all the shapes just need to be learned once. More importantly maybe, C++ doesn't lend itself well to thinking about game ideas, whereas Kismet does...

                          So taking a step back, I suggest you learn Kismet, read Henrik's guides and watch YouTube videos. This will teach you the core properties and the object model unrealscript uses, and give you a deeper understanding of the actors you'll be working with in UDK. After you've got that bit down, learn how to create custom Kismet nodes which extend Kismet, and this will lead you gently into learning unrealscript full-time.

                          Can't help with Swarm as I use Dynamic Lighting exclusively, which I recommend if you're making PC games. But there are loads and loads of posts about setting up Swarms. It is a bit fiddly sometimes just to warn you.

                          Sorry, I didn't follow the 'Pop-Out' question at all. Are you taking about ADA's? Unless you build 'houses' out of Movers that move, or RigidBodies / Kactors or ADA's, there's no possibility of a UDK 'house' popping out. So not sure why you would say this. Maybe its lighting or something else that's throwing you here. In general, static meshes are absolutely static!

                          Packing Interpactors or merging FX is simple, its all done in the level editor, its just combining actors, no code, and hardly any kismet except maybe spawning actors...

                          Comment


                            #14
                            Caeon, a last thing you want a wiki to look like, it's personal, if you want others to edit it, and such you will have to remove opinions and other stuff that make it look like rather than a community public documentation place, a blog.

                            Blogs are blogs. Documentation sites are documentation sites.

                            Opinions un-related to the learning subject are just already irrelevant infromation.

                            Comment


                              #15
                              @ Neongho

                              OK, than lets call it a Blog in a form of a wiki. ^^ BTW there is a Blog function I could enable, but I don't like Blog's I like more the structure of a Wiki. And I see that there is not much interest in creating a UDK Wiki and so I working a bit on it play a round a bit and came back later and IF there is more content maybe there is more interest, idk. I see now that is a bit to big for me but I look how far I came and maybe I give up if it suck up to much of my time.

                              So, thanks again for telling me your opinions, that help me to go in the right way even if I am a bit stubborn, I just wont give up this idea! ^^


                              @ frankit

                              Thaks for you advise related to C++ and co.

                              Yeah I would use dynamic lighting only too but at the moment any ADA that is illuminated by it are casting deep black shadows and I think I have to simulate the light bouncing manually, but I need more practical experience about lighting and stuff.

                              And about the ADA and other actors and combination of them I think I mixed up some things and just talking/asking bull****^^.
                              I follow you advise reading and watching some tutorials to gather more knowledge and cam back later, so that I am more know what going on In UDK.

                              So, thanks again for putting me in the right direction.

                              Comment

                              Working...
                              X