Unreal Wiki - User contributions [en]

Unreal Wiki talk:Offline Wiki

2008-07-08T21:46:40Z

DalinSeivewright: Reply

== Offline wiki? ==
The main page redirects here with the description that an offline snapshot of this wiki should be downloadable here, but I only see a blank page. You may want to fix it to give people an alternative for using offline readers. [[User:Hyper|Hyper]] 06:52, 8 July 2008 (UTC)

Either sometime before the switchover to the new wiki system or just after, the Offline Wiki was (most likely temporarilly) stopped. From looking [[Legacy:Offline_Wiki | on the legacy page of the old wiki content]] it states that the download link from BeyondUnreal is currently unavailable. I believe the offline wiki was compiled every week from an automatic script and that the old script doesn't work with the new system yet. You may be able to find copies of the Offline Wiki on sites like FilePlanet or FileFront but they may be slightly out of date and definitely would not account for the updates with the new wiki system and most of the UE3 content that we now have, but
fear not! Lately work hasn't seemed to be going along with the wiki for a few weeks and its still in some state of change but once everything is worked out the Offline Wiki will surely be up again. Sorry for any inconvenience. -[[User:DalinSeivewright|DalinSeivewright]] 21:46, 8 July 2008 (UTC)

UE3 talk:Actor native functions (UT3)

2008-05-28T16:26:20Z

DalinSeivewright: Purpose of Out Variables with functions like Trace

After talking to a trusted colleague about UnrealScript's use of '''out''' variables and why Java doesn't support them. He tells me its a bad idea because "Generally speaking '''out''' parameters are a form of pass by reference which essentially creates methods with multiple return types. There is some additional security but risks of spin-off effects exist. A preferred programming structure is to encapsulate the return types and the out variables into a new composite object."

I see some common sense in this, while working with Java, as it is slightly easier to just make a seperate private class and return that if there are multiple return types needed. With UnrealScript, I love the ability to simply create structures to do the same.

I don't neccesarilly agree with it in terms of UnrealScript though, most because I've been working for a long time and have grown acustom to it. But if what he says is slightly true, then there must be a reason why UnrealScript uses '''out''' variables Specifically for the Trace function where rather than the Hit object being returned, a HitCollision object would be returned that would hold a reference to the actual actor as well as HitLocation (or HitComponent with UT3?) etc...

The purpose for this may be memory usage and optimization but I would like input on this as its interesting to see why they would keep '''out''' variables eversince UE1. -[[User:DalinSeivewright|DalinSeivewright]] 16:26, 28 May 2008 (UTC)

User talk:DalinSeivewright

2008-05-19T01:59:50Z

DalinSeivewright: reply

==Plans==
I plan on working in the Custom Actor sections soon. Moving things around, formatting, etc.

:Please don't just move legacy content. This would imply a license change, which is slightly dodgy. I think content should be rewritten, unless the one moving it was the only contributor to the legacy page. --[[User:Wormbo|Wormbo]] 09:50, 3 April 2008 (UTC)

:So I guess we're keeping the Legacy category then. Would this also mean that we're going to strictly focus on new UE3 content rather than continuuing 'support' for older content? With regards to the recent Open Source page I was working on (trying to find a nice combination to combine the old legacy pages) should I just scrap them or do you think we should have new pages for new open source scripts and classes that people would like to add?--[[User:DalinSeivewright|DalinSeivewright]] 10:19, 3 April 2008 (UTC)

::As much as I would like to allow moving content from Legacy:, there's no real way to reconcile the licenses. And keeping the old license is basically not an option IMO. While the transition will certainly be easier for UE3 content as there isn't much of it existing yet, we still would like to have content for older engines/games created. There is a bit to discuss with the transition, and there are others who will be joining in, so more general questions and feedback should probably go on the [[Talk:Main Page|main page discussion]]. – [[User:Haarg|Haarg]] 10:38, 3 April 2008 (UTC)

Hey Dalin, quick question: are you still in Regina? —''[[User:Graphik|Graphik]] 04:27, 15 May 2008 (UTC)''

No I moved to MJ for school in January. Lyzzeh moved to Vancouver though. Or is in the process of doing so. -[[User:DalinSeivewright|DalinSeivewright]] 05:49, 15 May 2008 (UTC)

Her sister said Lyzz had moved a few days ago and would be staying with a few people she had met on the 'net. Given that you've pictures of a "new house" on Flickr — well, you've likely guessed the rest already.

Thanks for sharing this ostensibly Unreal-related information. —''[[User:Graphik|Graphik]] 21:19, 18 May 2008 (UTC)''
:I'm guessing she never told you? -[[User:DalinSeivewright|DalinSeivewright]] 01:59, 19 May 2008 (UTC)

User talk:DalinSeivewright

2008-05-15T05:49:24Z

DalinSeivewright: reply

==Plans==
I plan on working in the Custom Actor sections soon. Moving things around, formatting, etc.

:Please don't just move legacy content. This would imply a license change, which is slightly dodgy. I think content should be rewritten, unless the one moving it was the only contributor to the legacy page. --[[User:Wormbo|Wormbo]] 09:50, 3 April 2008 (UTC)

:So I guess we're keeping the Legacy category then. Would this also mean that we're going to strictly focus on new UE3 content rather than continuuing 'support' for older content? With regards to the recent Open Source page I was working on (trying to find a nice combination to combine the old legacy pages) should I just scrap them or do you think we should have new pages for new open source scripts and classes that people would like to add?--[[User:DalinSeivewright|DalinSeivewright]] 10:19, 3 April 2008 (UTC)

::As much as I would like to allow moving content from Legacy:, there's no real way to reconcile the licenses. And keeping the old license is basically not an option IMO. While the transition will certainly be easier for UE3 content as there isn't much of it existing yet, we still would like to have content for older engines/games created. There is a bit to discuss with the transition, and there are others who will be joining in, so more general questions and feedback should probably go on the [[Talk:Main Page|main page discussion]]. – [[User:Haarg|Haarg]] 10:38, 3 April 2008 (UTC)

Hey Dalin, quick question: are you still in Regina? —''[[User:Graphik|Graphik]] 04:27, 15 May 2008 (UTC)''
No I moved to MJ for school in January. Lyzzeh moved to Vancouver though. Or is in the process of doing so. -[[User:DalinSeivewright|DalinSeivewright]] 05:49, 15 May 2008 (UTC)

Category talk:Programming tutorials

2008-05-13T00:11:14Z

DalinSeivewright:

computergod666: WHAT ON EARTH HAPPENED?!! The site switches engines and all the UT-related information is gone! Not sheerly out of curiosity, where do I go for it now?
:Try doing a search. — [[User:Haarg|Haarg]] 20:28, 12 May 2008 (UTC)
:Please read the front page. It will answer some of your questions. -[[User:DalinSeivewright|DalinSeivewright]] 00:11, 13 May 2008 (UTC)

UE2:UT2004 Default.ini

2008-04-29T04:30:27Z

DalinSeivewright:

==Default.ini File in your UT2004\System Directory==
Contains settings which are used for creating the '''UT2004.ini''' on your first run of the game. Thats why you'll find this file is very similar to [[Legacy:UT2004.Ini|UT2004.ini]]].

The '''Default.ini''' is also used when creating a mod using the mod system included with '''UT2k4'''.This file will contains all links required to run custom content in your modification using the '''-mod=''' switch. Although use of the mod system is not required it is recommended.<br><br>

==Using Default.ini to Compile with mod Support.==
To compile your mod using the '''-mod=''' commandline switch you must first create a '''Default.ini''' in your '''UT2k4Dir\ModRootDir\System'''.

===Template===
:I have provided this template below as a guide, to use it simply replace '''YourMod''' with your modification's directory, please be consistant. Also replace the mod '''ModServerPackage''' and the '''ModEditPackage''' packages with your own, you do not need to replace server packages if you arn't going to use your mod online. You can use more than one package in this file just replicate the '''ServerPackages=''' and/or '''EditPackages=''' as many times is needed.

::[Core.System]
::+MusicPath=../'''YourMod'''/Music
::-CacheRecordPath=../System/*.ucl
::+CacheRecordPath=../'''YourMod'''/System/*.ucl
::+CacheRecordPath=../System/*.ucl
::+Paths=../'''YourMod'''/System/*.u
::+Paths=../'''YourMod'''/Maps/*.ut2
::+Paths=../'''YourMod'''/Textures/*.utx
::+Paths=../'''YourMod'''/StaticMeshes/*.usx

::[Engine.GameEngine]
::+ServerPackages='''YourModPackage'''

::[Editor.EditorEngine]
::+EditPackages='''YourModPackage'''

===Merging and Operators===
:When you compile or run with the '''-mod=''' commandline switch '''YourMod\System\Default.ini''' file will be merged with the current '''UT2004.ini''' in your ''UT2004\System'' directory and a new ini file will be created in your '''YourMod\System''' and will have the same name as the '''YourMod'''. If no '''UT2004.ini''' is present the resultant ini file will be created from merging '''Default.ini''' in the in your ''UT2004\System'' directory and the one from '''YourMod\System'''.<br><br>

:The '''+''' and '''-''' are operators (Reffered to on UDN as modifiers) these are used to add and subtract Keys ([[Types#Dynamic_array|Dynamic Arrays]]) like Paths, ServerPackages, EditPackages from the current '''UT2004.ini'''.

::'''-Paths=../Textures/.utx''' – This for example, would remove the original texture package directory from the resultant '''Mod.ini''' File.<br><br>

:If no operator exists, one of two things will happen:
:#If the key already exists the value of the key will be overwritten by the new value.
:#If the key does not exist, the key and value will be added.<br><br>

:Using the ''';''' before a key or operator will add the key to the ini but it will be commented out. So you can add values that you may use but dont use often etc and remove the ''';''' from your '''YourMod.ini'''<br>

:Another good technique for speeding compile times is to use and for supressing packages in the '''YourMod.ini'''.

::''';EditPackages=YourModPackage'''

:This technique can also be used for the '''Default.ini''':

::'''-EditPackages=YourModPackage'''
::'''+;EditPackages=YourModPackage''' or ''';EditPackages=YourModPackage'''<br>

{{ambox|type=notice|text=Using: ''';+EditPackages=YourModPackage''' will add this exact line to the ini, I recommend using ''';EditPackages=YourModPackage''' instead.}}<br>

:Keys get processed in the order they appear, This can be useful as in the following:
::'''-CacheRecordPath=../System/*.ucl'''
::'''+CacheRecordPath=../TestMod/System/*.ucl'''
::'''+CacheRecordPath=../System/*.ucl'''

:This is actually recommended because all cache files will be placed in the first '''CacheRecordPath''' found. Since this removes the '''CacheRecordPath''' used by UT2k4 then inserts the mods '''CacheRecordPath''' followed by the UT2k4 one this means the mods Path will appear before UT2k4's in '''YourMod.ini'''.

===Notes===
*Trying to modify the '''UT2k4\SaveDir'''will make the game crash instead you can set UT2K4SP_Main.default.ProfilePrefix="Mod_" and it will keep you save games seperate from in the '''ModRootDir\Saves''' dir.'''-Paths=../Saves/*.uvx'''
*Things not to do when creating a '''deafult.ini'''
**You have been able to change the MusicPath since 3204. Since Beta 3229+ MusicPath has become an Array and you can set it up like:

{{ambox|type=notice|text=
'''+MusicPath=../Mod/Music'''
"not"
'''+Paths=../Mod/Music/*.ogg'''.
}}<br><br>

==Links==
*[[Legacy:Game Ini File|Game Ini File]]
**[[Legacy:UT2004.Ini|UT2004.ini]]
***[[UE2:UT2k4Mod.ini|UT2k4Mod.ini]] – For Epics Mod system
***UT2k4 Default.ini – Used for generating UT2004.ini's
***[[Legacy:UT2k4 DefaultUser.Ini|UT2k4 DefaultUser.ini]] – Used for generating UT2004.ini's<br><br>

==External Links==

:*[[udn2:ImprovedModSupport|Improved Mod Support]]

UE2 talk:UT2k4Mod.ini

2008-04-29T04:29:19Z

DalinSeivewright: UE2 talk:UT2k4Mod.Ini moved to UE2 talk:UT2k4Mod.ini: Fixed Olympus :D

Oh shi... Meant to have a lowercase I on the UT2k4Mod.ini :\ -[[User:OlympusMons|OlympusMons]] 03:20, 29 April 2008 (UTC)

UE2 talk:UT2k4Mod.Ini

2008-04-29T04:29:19Z

DalinSeivewright: UE2 talk:UT2k4Mod.Ini moved to UE2 talk:UT2k4Mod.ini: Fixed Olympus :D

#REDIRECT [[UE2 talk:UT2k4Mod.ini]]

UE2:UT2k4Mod.Ini

2008-04-29T04:29:18Z

DalinSeivewright: UE2:UT2k4Mod.Ini moved to UE2:UT2k4Mod.ini: Fixed Olympus :D

#REDIRECT [[UE2:UT2k4Mod.ini]]

UE2:UT2k4Mod.ini

2008-04-29T04:29:18Z

DalinSeivewright: UE2:UT2k4Mod.Ini moved to UE2:UT2k4Mod.ini: Fixed Olympus :D

The '''UT2k4.ini File''' is used when creating a mod using the inbuilt mod system included with '''UT2k4'''. It contains Descriptions and links to your mod, modlogo and even your mod's url.

When running with the '''-mod=''' commandline switch, [[UT2004]] will look for this file in your C:\ut2004\'''YourMod''', if found it will load the custom '''ini''' file.

{{ambox|type=notice|text= In truth, the content of this file is only referenced by the "User Mods" tab of the community menu. Think of it as the "definition" file for you mod. It contains the the various text and options needed to fill out that menu. – UDN
}}<br>

==General Information on the ut2k4mod.ini==
;[Mod] : This is the section header and it *MUST* be the first item of your UT2K4MOD.ini file. Without it your mod will not display.
;ModTitle : This is the title of the mod and will be displayed in the select list of the "User Mods"tab.
;ModLogo : This is the full name (ie: Package.texture) of the image to be displayed on the "User Mods"tab of the community menu when someone selects your mod. It should be 512x128.
;ModDesc : This options sets the description that will show in the box on the "User Mods"tab. You can use the pipe character "|"to add CR/LF’s to the display.
;ModCmdLine : This is the command line that will be used to launch your mod. You do not need to include the "–mod="as it will be auto-appended.
;ModURL : This is a hyperlink to a web site for your mod.

Template

<Uscript>

[Mod]

ModTitle=

ModLogo=

ModDesc=

ModCmdLine=

ModURL=
</Uscript><br><br>

==Related Topics==
* [[Legacy:Set Up Package Folders|Set Up Package Folders]]
* [[Legacy:Game Ini File|Game Ini File]]
**[[Legacy:UT2004.Ini|UT2004.ini]]
***UT2k4Mod.ini
***[[UE:UT2004 Default.Ini|UT2004 Default.ini]] – Used for generating UT2004.ini's
***[[Legacy:UT2k4 DefaultUser.Ini|UT2k4 DefaultUser.ini]] – Used for generating User.ini's<br><br>

==External Links==
:*[[udn2:ImprovedModSupport|Improved Mod Support]]

User talk:DalinSeivewright/Developer Journal

2008-04-26T22:28:50Z

DalinSeivewright:

==Thursday, April 26th, 2008==
<span id="APRIL262008" name="APRIL262008"></span>
The following is the entry discussion for [[User:DalinSeivewright/Developer_Journal#APRIL262008|Thursday, April 26th, 2008]].

User:DalinSeivewright/Developer Journal

2008-04-26T22:28:30Z

DalinSeivewright:

<center>{{classbox| Welcome To Dalin Seivewright's Wiki Developer Journal.}}

This page is used by Dalin Seivewright to post his developer related thoughts, open source code, and concepts. The journal entries are on this page while the discussions for every entry are available on the [[User_talk:DalinSeivewright/Developer_Journal|discussion page]]. If you wish to to join in on the discussion or if there isn't one already started on a particular entry, feel free to start one yourself.

{{classbox| Journal Entries are sorted from newest to oldest by date.}}</center>

----

=Journal Entries=
==Thursday, April 26th, 2008==
<span id="APRIL262008" name="APRIL262008"></span>

Recently I started a little (read: extremely small) project in UnrealScript to try and get back into the swing of things. After just finishing the moving Jumper, I was semi-inspired by the concept of 'jumping'. I decided to make a 'jumper' that would instantly jump a player to where they wanted to go. This would make cross-map travelling a breeze and is a decent alternative to the Translocator (and safer). I got a prototype weapon up and running in no time, which kind of surprised me. The jumper weapon itself is very simple. Once you shoot in a direction, a trace occurs and returns the hit location of your shot. Then you can use the secondary fire mode to transport yourself to that hit location. In the movie, the effect that occurs when the person jumps is neat, but not entirely practical for a fast paced game like UT2004 in which effects shouldn't last very long. Therefore I decided to use the affect that... erm... forgive my non-knowledge of X-men, but the blue guy that can teleport places. :\ This effect is a puff of smoke where he teleports from and teleports to and is rather quick to dissipate. This effect for my jumper weapon would do well as its 'neat' and gives other players the knowledge that a player just teleported 'somewhere' without being too distracting. The Translocator in UT2004 has a use limit on it that recharges and when you pick up the Flag and translocate, you drop the flag. Being that I've never been a fan of the Translocators use-limit, I won't be including one with the Jumper. I will however only allow the jumper to be used every 3-4 seconds or so. This would cut down on lag from spamming the effect and will perhaps cut down on the 'lame' factor. As far as I stand on the dropping the flag issue, I just don't know if I want to do that. The idea of instantly jumping from one side of the map to the other puts into effect the need for a faster paced game and allowing Jumpers to use such a device to carry the flag from the enemy base to their base would require players to be quick about what they're doing. Allowing the flag to be jumped would also most likely require the addition of 4-5 extra seconds before they can jump, just to be fair.

As of yet, the AI's use of the weapon is non-existent as they just don't know how and I've made some fixes to the HitLocation to prevent players from not jumping due to them not being able to fit in a given location (for example, a small hole). I've added a check to put them as near to the HitLocation as they can go. Which also brings up a humorous bug I squashed while trying to find a solution to the afforementioned bug. Using the Jumper and shooting at a location like the corner of the wall then turning around to jump, you could actually Jump yourself on the other side of the wall (if there is another side).

Anyways. I don't forsee any problems with not finishing this. I may or may not release it but I doubt it would have any practical use as 1. UT2004 as far as decent servers using customizations that don't relate to IG or RPG and 2. It probably isn't very appealing. Nonetheless, we'll see. As usual, I plan on release it as open source, just for fun.

===Entry Source Code===
There's no source code with this entry.
===Entry Disussion===
For discussion on this entry, please see [[User_talk:DalinSeivewright/Developer_Journal#APRIL262008|the discussion page]].

=ENTRY TEMPLATE=
==Thursday, April 24th, 2008==
<span id="APRIL242008" name="APRIL242008"></span>
(placeholder)
===Entry Source Code===
<div class="hidden-block"><span class="hint">Source Code 1</span><div class="hidden">(placeholder)</div></div>
===Entry Disussion===
For discussion on this entry, please see [[User_talk:DalinSeivewright/Developer_Journal#APRIL242008|the discussion page]].

Talk:Main Page

2008-04-25T18:23:24Z

DalinSeivewright: reply for mod ideas

== General layout ==

I've tried to come up with a compact initial layout and topic list. Suggestions for improvements are welcome. [[User:Wormbo|Wormbo]] 06:31, 13 March 2008 (EDT)

Actually, we need to come up with an easy-to-browse structure for overview pages of the various parts of Unreal modding. The problem here will be that either this kind of page tends to get too long or there are too many pages to click through before reaching actual content. We need to find a good mix between an sophisticated structure and quick access. The topic pages can be accompanied by [[Project:categories|categories]], navigation/info boxes (an example can be found e.g. on [[Literals]]) and disambiguation links/pages for when a user uses the Go button of the search box in the sidebar. I hope this will give you an overview of the new tools we can use to structure the Unreal Wiki. -[[User:Wormbo|Wormbo]] 07:58, 16 April 2008 (UTC)

I think we can now all agree this should have been discussed openly and decided much earlier, before the switch to MediaWiki and the subsequent disconnect with Legacy content. This discussion will likely last a while and not get the input of the entire wiki community. Seeing as I was an instrumental contributor of the old organization (which has been widely criticized as poor or no organization), I will step back, keep an eye on the progress and wait for the dust to settle. Good luck. -[[User:SuperApe|SuperApe]] 08:57 PST, 16 April 2008

Under the UnrealScript Reference topics, seeing 'Programming tutorials' seems a little out of place. Since most if not all the programming tutorials we have here will deal with UnrealScript, why not change it and the category to UnrealScript Tutorials? -[[User:DalinSeivewright|DalinSeivewright]] 15:14, 17 April 2008 (UTC)

These category things are working arnt they? Ive been around the site acouple of times now and I dont think Ive seen anything in any of the expanded tree's. Just wondering anyways, perhaps we could get some templates in there with correct names for the time being. -[[User:OlympusMons|OlympusMons]] 22:49, 17 April 2008 (UTC)

Those tree widgets only show subcategories, not pages or media. Just imagine [[:Category:UT2004-specific classes]] displaying all old UT2004 classes when you expand its subcategory [[:Category:Legacy Class (UT2004)]]! If you mean the actual categories, don't worry. I'll import the wikified class pages for UT, UT2003/4, UT3 and UE2Runtime some time this week. -[[User:Wormbo|Wormbo]] 08:35, 21 April 2008 (UTC)

Yeah I noticed that an hour or so after making that comment, I thought classes were meant to be shown in the category class tree's but they arnt, it seems to function more like a search criterea. Yeah hope things are going well on the new wikifier, should save alot of time. :)
Actually on the Topic of class tree's since Im there, whats going to happen in that respect now? Are we going to have a class tree page anymore? I imagine alot can be done with tree views now so Id wonder if it is possible to have a class tree which is actually expandable/collapsable now, since the categories dont show the classes right under their package or superclass etc -[[User:OlympusMons|OlympusMons]] 23:29, 21 April 2008 (UTC)

== New wiki software / Organization ==
Various people have had questions, comments, or criticisms of this move to MediaWiki. This seems as good a place as any to discuss it, so feel free to add anything here. – [[User:Haarg|Haarg]] 21:32, 3 April 2008 (UTC)

:Well I guess my biggest concern is the wealth of existing information (namely the tutorials and class hierarchy pages) that we can't simply move over. Most if not all the pages have had at least one contributor to the page that has done at least a minor edit. Then there's the problem of not having a complete history of the older pages so while it may appear that only one individual has worked on a given page, the truth could be that at least two have worked on it but the history of the page has been lost. Then theres the problem of what we can do with new content for the older engines as we cannot add new content to these legacy pages. IMO, the class hierarchy at least could be moved over as most of the pages are simply descriptions of what the class does (which really, Copyrights should have no hold over because there's only so many ways you can describe what a class is responsible for) and have listings for each method and variable and what they're used for.

:If that really is not an option then we could go through class by class and (re-) create a class page for each of them by source. So we could have a category for each game and have a hierarchy of classes from each package. It '''would''' take a fair bit of time to complete and a decent format would need to be made up. I personally didn't like how the old formats were set up. It seemed like too much information was being thrown at you for classes such as Actor, where there are a lot of variables and methods to go through. I guess we'd have to look at how much more information we could add in the end. I'm not sure how 'definitive' our class pages were, but I'm positive we didn't have many pages for certain classes.

:On the topic of tutorials, is there any reason why we can't re-write them? If a tutorial explains how to make a new weapon based on the shock rifle (which has been over done already) we could just reinvent the wheel. The other more advanced tutorials (such as the RPG Class tutorials) could be re-written with a similar basis.

:In the end, I think keeping the older content up-to-date and easy to find/navigate through is important as many level designers and modders most likely have not moved over to UE3 and UE2 still has plenty of life left in it.

:-[[User:DalinSeivewright|DalinSeivewright]] 12:03, 4 April 2008 (UTC)
::Most of the class hierarchy could be moved over or recreated pretty simply. As for tutorials, rewriting them is probably the best solution. While that may seem like wasted effort, I don't see a better solution given the licensing issues. – [[User:Haarg|Haarg]] 17:17, 5 April 2008 (UTC)
:wow. Unreal Wiki had a makeover... This will be confusing for a while...--[[User:JeffMOD|JeffMOD]] 14:56, 5 April 2008 (UTC)
:A comment on user accounts: It probably could have been explained better, but the user accounts from the old wiki weren't converted to the new software. First, I somewhat doubt it would have been possibly technically But mainly, there was barely any information attached to the old accounts that have been worth keeping. So everyone has to create new user accounts. Additionally, anonymous edits are turned off. I would be interested in feedback on that as well. – [[User:Haarg|Haarg]] 17:17, 5 April 2008 (UTC)
::I think its a great idea. Its a good anti-spam addition that works well for the most part, although it could end up generating a lot of accounts that would only be used once (as I've found a lot of people often to go to a site where they need to sign up to contribute and only ever change one thing they've found). Also, spam bots have been known to sign up a lot so perhaps you could add CAPTCHA to the account creation process. -[[User:DalinSeivewright|DalinSeivewright]] 02:30, 6 April 2008 (UTC)
:::I don't think we need to add a captcha at this point, but that could be revisited if spam becomes a problem. – [[User:Haarg|Haarg]] 02:36, 6 April 2008 (UTC)

Two things. Having the Legacy article show up in the search kind of makes it look incredibly messy, unorganized and hard to follow. I understand that its important to stress that Users probably shouldn't do major edits to Legacy pages but somehow hiding the Legacy part of the article name would help things considerably.

Secondly I was comparing the Actor class of UT2003 with that of UT2004 and there are several differences in each. I think we should have at least one Actor page for each generation but what about games within the same generation? Should we have seperate Actor pages for UT2003 and UT2004 within the UE2 namespace or UT2003/UT2004 namespaces or should we have one full page for UT2004 and have a seperate page for the Actor class in UT2003 that just sites the major differences? -[[User:DalinSeivewright|DalinSeivewright]] 01:32, 15 April 2008 (UTC)
:Well on the topic of UE2 Id think the best option might be to have a seperate section relating to UE2.5 since its an upgrade on the engine. Both UT2003 and UT2004 are UE2 though but other engines picked up support at UE2.5 where some are based on UE2. I do know there was alittle bit of a hastle with the class tree pages because it contained info from both UE2-2.5 so each difference had to be tagged. I guess it wasnt so bad since some classes are identical between the two, the last idea sounds good to me to do full page on UT2004's Actor and a differences page for UT2003. - [[User:OlympusMons|OlympusMons]]

:::I actually change my mind. I think we should have an actor page for each version of the engine/game. This would be considerably more work (unless Wormbo finishes his class wikifier?) but it would be much 'cleaner' and dare I say sexier. Plus users won't be too confused on whether or not their on the right page if the page just sites the differences. -[[User:DalinSeivewright|DalinSeivewright]] 00:11, 17 April 2008 (UTC)

::::Might be the go hey since there are sometimes differences between builds as well so it might get very confusing later, duplicating material isnt too good but I dont think it can be helped much since of the nature of UE. -[[User:OlympusMons|OlympusMons]] 22:51, 17 April 2008 (UTC)

:::I agree with Dalin here. Each "game" (including UE2Runtime) gets its own set of class pages and corresponding categories. If the classes really have exactly the same content, we can take advantage of the template features and simply include the newest game's version of the page on all older games' versions of the same page. I already demonstrated this on [[UE2:DMRosterBeatTeam (UT2003)]], which only includes the content from [[UE2:DMRosterBeatTeam (UT2004)]]. The templates [[Template:Infobox class]] (and [[Template:Infobox class part]]) and [[Template:samegame]] used there automatically set up links to point to pages of the same game.<br/>On a semi-related note: Do we want to document defaultproperties, possibly including subobjects, on the class pages? -[[User:Wormbo|Wormbo]] 08:35, 21 April 2008 (UTC)

::::I'm in favor of having any documentation of the default properties in where the variables are documented (if at all). It would seem reasonable to have the 'default' or accepted values for a given variable where we've explained what the variable is for. I think subobjects should be included too, just as long as we can have a seperate page for that sub-object if it is really important. For example, the KPhysics object in xPawn. Without it, your Pawn fails. -[[User:DalinSeivewright|DalinSeivewright]] 05:49, 22 April 2008 (UTC)

== Mod ideas ==

I dont know where to add mod ideas...

The mod ideas section didn't really work out on the old wiki, IMHO. Would it really make sense to revive that? -[[User:Wormbo|Wormbo]] 05:54, 25 April 2008 (UTC)
:I was actually thinking the same thing and wasn't going to add it to the main page, but then I thought I'd add it anyways and see what anyone else thought. The old Mod ideas was an okay source for ideas but it ended up being a list of abandoned pages with half being discussions on the Mod idea itself and the other half being discussions on the progress of the mod, as if it was no longer an open source idea but being worked on. I'm fine with not reviving the page, but where would these mod ideas go now? -[[User:DalinSeivewright|DalinSeivewright]] 06:26, 25 April 2008 (UTC)
::Better leave mod ideas to ppl's own wiki pages -[[User:0 Kelvin|0 Kelvin]]
:::That's a pretty good idea actually. There could be a category like [[:Category:Mod ideas]] or something similar, and it could go over what to have in mind of you are proposing a mod idea. Ideas could then be posted as sub-pages of user pages. If an idea actually took off, it could be moved into a different namespace easily. – [[User:Haarg|Haarg]] 15:47, 25 April 2008 (UTC)
::::Lets go with that then :) What about Licensing issues though? Will the 'concept' of Mod Ideas have to be reworked? If a user has a great concept and someone came and used that idea down to the exact details would there be any problems/need to cite references etc. ? I'm pretty sure copyright doesn't have a hold over 'ideas', although I could be wrong. -[[User:DalinSeivewright|DalinSeivewright]] 16:09, 25 April 2008 (UTC)
::::Isn't the entire point of posting mod ideas that ''others'' should pick them up? -[[User:Wormbo|Wormbo]] 16:59, 25 April 2008 (UTC)
:::::Yes of course, but since its under the Wiki license I'm simply wondering if there should be a seperate license for the idea pages, or if there would even be a need for that. I'm guessing by your comment, there should be no problem with the licensing then? :) -[[User:DalinSeivewright|DalinSeivewright]] 18:23, 25 April 2008 (UTC)

==Category link description==
Do the Wiki Categories currently support descriptions for each page associated to the category? What I mean is, is there currently a way to associate a description of a page within a category and have that description appear in the list of pages for said category? For example:
<pre>
A
[[Apple]] - This page describes what an apple is.
O
[[Orange]] - This page describes what an orange is.
</pre>
These descriptions would be added on the page with perhaps a little tag? I'm just curious and don't really feel they're neccesary... at least at the moment. -[[User:DalinSeivewright|DalinSeivewright]] 16:23, 25 April 2008 (UTC)

No, that's not supported. This type of description needs to go in the page text, either of the category page or a more suitable topic page. -[[User:Wormbo|Wormbo]] 16:54, 25 April 2008 (UTC)

Some form of this could be done using a DPL report:<dpl>
category = Custom UE2-specific classes
include={Infobox class}:parent1
includematch=/./
secseparators= \n- Subclass of ,
</dpl>
But that would be built as a specific list, and not part of the general category page. – [[User:Haarg|Haarg]] 17:49, 25 April 2008 (UTC)

Talk:Main Page

2008-04-25T16:23:56Z

DalinSeivewright: Category link description

== General layout ==

I've tried to come up with a compact initial layout and topic list. Suggestions for improvements are welcome. [[User:Wormbo|Wormbo]] 06:31, 13 March 2008 (EDT)

Actually, we need to come up with an easy-to-browse structure for overview pages of the various parts of Unreal modding. The problem here will be that either this kind of page tends to get too long or there are too many pages to click through before reaching actual content. We need to find a good mix between an sophisticated structure and quick access. The topic pages can be accompanied by [[Project:categories|categories]], navigation/info boxes (an example can be found e.g. on [[Literals]]) and disambiguation links/pages for when a user uses the Go button of the search box in the sidebar. I hope this will give you an overview of the new tools we can use to structure the Unreal Wiki. -[[User:Wormbo|Wormbo]] 07:58, 16 April 2008 (UTC)

I think we can now all agree this should have been discussed openly and decided much earlier, before the switch to MediaWiki and the subsequent disconnect with Legacy content. This discussion will likely last a while and not get the input of the entire wiki community. Seeing as I was an instrumental contributor of the old organization (which has been widely criticized as poor or no organization), I will step back, keep an eye on the progress and wait for the dust to settle. Good luck. -[[User:SuperApe|SuperApe]] 08:57 PST, 16 April 2008

Under the UnrealScript Reference topics, seeing 'Programming tutorials' seems a little out of place. Since most if not all the programming tutorials we have here will deal with UnrealScript, why not change it and the category to UnrealScript Tutorials? -[[User:DalinSeivewright|DalinSeivewright]] 15:14, 17 April 2008 (UTC)

These category things are working arnt they? Ive been around the site acouple of times now and I dont think Ive seen anything in any of the expanded tree's. Just wondering anyways, perhaps we could get some templates in there with correct names for the time being. -[[User:OlympusMons|OlympusMons]] 22:49, 17 April 2008 (UTC)

Those tree widgets only show subcategories, not pages or media. Just imagine [[:Category:UT2004-specific classes]] displaying all old UT2004 classes when you expand its subcategory [[:Category:Legacy Class (UT2004)]]! If you mean the actual categories, don't worry. I'll import the wikified class pages for UT, UT2003/4, UT3 and UE2Runtime some time this week. -[[User:Wormbo|Wormbo]] 08:35, 21 April 2008 (UTC)

Yeah I noticed that an hour or so after making that comment, I thought classes were meant to be shown in the category class tree's but they arnt, it seems to function more like a search criterea. Yeah hope things are going well on the new wikifier, should save alot of time. :)
Actually on the Topic of class tree's since Im there, whats going to happen in that respect now? Are we going to have a class tree page anymore? I imagine alot can be done with tree views now so Id wonder if it is possible to have a class tree which is actually expandable/collapsable now, since the categories dont show the classes right under their package or superclass etc -[[User:OlympusMons|OlympusMons]] 23:29, 21 April 2008 (UTC)

== New wiki software / Organization ==
Various people have had questions, comments, or criticisms of this move to MediaWiki. This seems as good a place as any to discuss it, so feel free to add anything here. – [[User:Haarg|Haarg]] 21:32, 3 April 2008 (UTC)

:Well I guess my biggest concern is the wealth of existing information (namely the tutorials and class hierarchy pages) that we can't simply move over. Most if not all the pages have had at least one contributor to the page that has done at least a minor edit. Then there's the problem of not having a complete history of the older pages so while it may appear that only one individual has worked on a given page, the truth could be that at least two have worked on it but the history of the page has been lost. Then theres the problem of what we can do with new content for the older engines as we cannot add new content to these legacy pages. IMO, the class hierarchy at least could be moved over as most of the pages are simply descriptions of what the class does (which really, Copyrights should have no hold over because there's only so many ways you can describe what a class is responsible for) and have listings for each method and variable and what they're used for.

:If that really is not an option then we could go through class by class and (re-) create a class page for each of them by source. So we could have a category for each game and have a hierarchy of classes from each package. It '''would''' take a fair bit of time to complete and a decent format would need to be made up. I personally didn't like how the old formats were set up. It seemed like too much information was being thrown at you for classes such as Actor, where there are a lot of variables and methods to go through. I guess we'd have to look at how much more information we could add in the end. I'm not sure how 'definitive' our class pages were, but I'm positive we didn't have many pages for certain classes.

:On the topic of tutorials, is there any reason why we can't re-write them? If a tutorial explains how to make a new weapon based on the shock rifle (which has been over done already) we could just reinvent the wheel. The other more advanced tutorials (such as the RPG Class tutorials) could be re-written with a similar basis.

:In the end, I think keeping the older content up-to-date and easy to find/navigate through is important as many level designers and modders most likely have not moved over to UE3 and UE2 still has plenty of life left in it.

:-[[User:DalinSeivewright|DalinSeivewright]] 12:03, 4 April 2008 (UTC)
::Most of the class hierarchy could be moved over or recreated pretty simply. As for tutorials, rewriting them is probably the best solution. While that may seem like wasted effort, I don't see a better solution given the licensing issues. – [[User:Haarg|Haarg]] 17:17, 5 April 2008 (UTC)
:wow. Unreal Wiki had a makeover... This will be confusing for a while...--[[User:JeffMOD|JeffMOD]] 14:56, 5 April 2008 (UTC)
:A comment on user accounts: It probably could have been explained better, but the user accounts from the old wiki weren't converted to the new software. First, I somewhat doubt it would have been possibly technically But mainly, there was barely any information attached to the old accounts that have been worth keeping. So everyone has to create new user accounts. Additionally, anonymous edits are turned off. I would be interested in feedback on that as well. – [[User:Haarg|Haarg]] 17:17, 5 April 2008 (UTC)
::I think its a great idea. Its a good anti-spam addition that works well for the most part, although it could end up generating a lot of accounts that would only be used once (as I've found a lot of people often to go to a site where they need to sign up to contribute and only ever change one thing they've found). Also, spam bots have been known to sign up a lot so perhaps you could add CAPTCHA to the account creation process. -[[User:DalinSeivewright|DalinSeivewright]] 02:30, 6 April 2008 (UTC)
:::I don't think we need to add a captcha at this point, but that could be revisited if spam becomes a problem. – [[User:Haarg|Haarg]] 02:36, 6 April 2008 (UTC)

Two things. Having the Legacy article show up in the search kind of makes it look incredibly messy, unorganized and hard to follow. I understand that its important to stress that Users probably shouldn't do major edits to Legacy pages but somehow hiding the Legacy part of the article name would help things considerably.

Secondly I was comparing the Actor class of UT2003 with that of UT2004 and there are several differences in each. I think we should have at least one Actor page for each generation but what about games within the same generation? Should we have seperate Actor pages for UT2003 and UT2004 within the UE2 namespace or UT2003/UT2004 namespaces or should we have one full page for UT2004 and have a seperate page for the Actor class in UT2003 that just sites the major differences? -[[User:DalinSeivewright|DalinSeivewright]] 01:32, 15 April 2008 (UTC)
:Well on the topic of UE2 Id think the best option might be to have a seperate section relating to UE2.5 since its an upgrade on the engine. Both UT2003 and UT2004 are UE2 though but other engines picked up support at UE2.5 where some are based on UE2. I do know there was alittle bit of a hastle with the class tree pages because it contained info from both UE2-2.5 so each difference had to be tagged. I guess it wasnt so bad since some classes are identical between the two, the last idea sounds good to me to do full page on UT2004's Actor and a differences page for UT2003. - [[User:OlympusMons|OlympusMons]]

:::I actually change my mind. I think we should have an actor page for each version of the engine/game. This would be considerably more work (unless Wormbo finishes his class wikifier?) but it would be much 'cleaner' and dare I say sexier. Plus users won't be too confused on whether or not their on the right page if the page just sites the differences. -[[User:DalinSeivewright|DalinSeivewright]] 00:11, 17 April 2008 (UTC)

::::Might be the go hey since there are sometimes differences between builds as well so it might get very confusing later, duplicating material isnt too good but I dont think it can be helped much since of the nature of UE. -[[User:OlympusMons|OlympusMons]] 22:51, 17 April 2008 (UTC)

:::I agree with Dalin here. Each "game" (including UE2Runtime) gets its own set of class pages and corresponding categories. If the classes really have exactly the same content, we can take advantage of the template features and simply include the newest game's version of the page on all older games' versions of the same page. I already demonstrated this on [[UE2:DMRosterBeatTeam (UT2003)]], which only includes the content from [[UE2:DMRosterBeatTeam (UT2004)]]. The templates [[Template:Infobox class]] (and [[Template:Infobox class part]]) and [[Template:samegame]] used there automatically set up links to point to pages of the same game.<br/>On a semi-related note: Do we want to document defaultproperties, possibly including subobjects, on the class pages? -[[User:Wormbo|Wormbo]] 08:35, 21 April 2008 (UTC)

::::I'm in favor of having any documentation of the default properties in where the variables are documented (if at all). It would seem reasonable to have the 'default' or accepted values for a given variable where we've explained what the variable is for. I think subobjects should be included too, just as long as we can have a seperate page for that sub-object if it is really important. For example, the KPhysics object in xPawn. Without it, your Pawn fails. -[[User:DalinSeivewright|DalinSeivewright]] 05:49, 22 April 2008 (UTC)

== Mod ideas ==

I dont know where to add mod ideas...

The mod ideas section didn't really work out on the old wiki, IMHO. Would it really make sense to revive that? -[[User:Wormbo|Wormbo]] 05:54, 25 April 2008 (UTC)
:I was actually thinking the same thing and wasn't going to add it to the main page, but then I thought I'd add it anyways and see what anyone else thought. The old Mod ideas was an okay source for ideas but it ended up being a list of abandoned pages with half being discussions on the Mod idea itself and the other half being discussions on the progress of the mod, as if it was no longer an open source idea but being worked on. I'm fine with not reviving the page, but where would these mod ideas go now? -[[User:DalinSeivewright|DalinSeivewright]] 06:26, 25 April 2008 (UTC)
::Better leave mod ideas to ppl's own wiki pages -[[User:0 Kelvin|0 Kelvin]]
:::That's a pretty good idea actually. There could be a category like [[:Category:Mod ideas]] or something similar, and it could go over what to have in mind of you are proposing a mod idea. Ideas could then be posted as sub-pages of user pages. If an idea actually took off, it could be moved into a different namespace easily. – [[User:Haarg|Haarg]] 15:47, 25 April 2008 (UTC)
::::Lets go with that then :) What about Licensing issues though? Will the 'concept' of Mod Ideas have to be reworked? If a user has a great concept and someone came and used that idea down to the exact details would there be any problems/need to cite references etc. ? I'm pretty sure copyright doesn't have a hold over 'ideas', although I could be wrong. -[[User:DalinSeivewright|DalinSeivewright]] 16:09, 25 April 2008 (UTC)

==Category link description==
Do the Wiki Categories currently support descriptions for each page associated to the category? What I mean is, is there currently a way to associate a description of a page within a category and have that description appear in the list of pages for said category? For example:
<uscript>
A
[[Apple]] - This page describes what an apple is.
O
[[Orange]] - This page describes what an orange is.
</uscript>
These descriptions would be added on the page with perhaps a little tag? I'm just curious and don't really feel they're neccesary... at least at the moment. -[[User:DalinSeivewright|DalinSeivewright]] 16:23, 25 April 2008 (UTC)

Talk:Main Page

2008-04-25T16:09:09Z

DalinSeivewright: reply to mod ideas

Talk:Main Page

2008-04-25T06:26:18Z

DalinSeivewright: Reply

Main Page

2008-04-25T04:10:19Z

DalinSeivewright: Added link to Mod ideas (not yet created)

'''Welcome to the {{SITENAME}}.''' This site's goal is to provide comprehensive documentation of the [[Unreal Editor]], [[UnrealScript]] and all technical aspects of the [[Unreal Engine]].

If you came here as a player and are looking for details about the Unreal series of games, head over to BeyondUnreal's [[Liandri:|Liandri Archives]]. If you are a server administrator looking for information about running servers for Unreal series games, try the [[uadmin:|Unreal Admin Wiki]] instead.

{{ambox|type=serious|text=Please refrain from using an offline reader or similar tools to download the entire Unreal Wiki.

These tools put an insane stress on the server and will most likely get you banned immediately. The Unreal Wiki has a very dynamic nature, but if you want to download a recent snapshot, try our downloadable [[Project:Offline Wiki|Offline Wiki]] archive.}}

{{ambox|type=notice|text=We've recently [[Unreal Wiki:MediaWiki conversion|switched]] to the [[wp:MediaWiki|MediaWiki]] engine, and we're taking this opportunity to refresh the site's organization and content. The old content is available in full at [[Legacy:Home Page|the legacy home page]]. During this transition, you'll notice many red-colored links, which point to pages that don't yet exist. [[Project:Community Portal|See how you can help]] form the new, improved {{SITENAME}}.}}

__NOTOC__ __NOEDITSECTION__
{| cellpadding="0" cellspacing="10px" style="width:100%;"
| id="topic-list" style="vertical-align:top;" |
==Community==
The [[Project:Community Portal|Community Portal]] is the general place to find out what's going on and what needs to be done on the {{SITENAME}}.

New to the {{SITENAME}}? Feel free to join the other {{NUMBEROFUSERS}} users by [[Special:Userlogin|registering]]. The {{SITENAME}} is a community project and you are invited to [[Project:Helping out|help improve]] it. [[Project:Getting started|Getting started]] provides some tips on how to get started!

==Content==
The quickest way to find what you're looking for usually is the search box on the left. Otherwise, try one of the topical starting points below.

===General topics===
* [[Unreal Engine overview]]
* [[Modding overview]]
* [[Modding ideas|Modding ideas]]

===Mapping reference===
* [[Unreal Editor overview]]
* [[Mapping concepts]]
* [[:Category:Mapping tutorials|Mapping tutorials]]

===UnrealScript reference===
* [[UnrealScript overview]]
* [[:Category:Classes|UnrealScript API]]
* [[:Category:Programming tutorials|UnrealScript tutorials]]

===Modeling reference===
* [[Modeling overview]]
* [[:Category:Modeling tutorials|Modeling tutorials]]

Still can't find what you were looking for? You can browse through all of the [[:Category:Article categories|articles by category]] or the [[Legacy:Home Page|old {{SITENAME}} content]].

| style="vertical-align:top;" |
{| class="infobox infobox-pages" id="recent-edits" style="width:300px;float:none;margin-left:auto;"
|-
| style="text-align:center;font-size:smaller;" |''See [[Special:Recentchanges|Recent changes]] for all changes.''
|-
! Recent Updates
|-
|<dpl>
namespace=|UE1|UE2|UE3
count=5
ordermethod=lastedit
order=descending
mode=userformat
adduser=true
addeditdate=true
userdateformat=g:ia D, M j
format=<ul>,<li>[[%PAGE%|%TITLE%]]<br />%USER% - %DATE%,</li>,</ul>
noresultsheader=''None''
</dpl>
|-
! New Pages
|-
|<dpl>
namespace=|UE1|UE2|UE3
count=5
ordermethod=firstedit
order=descending
adduser=true
addeditdate=true
userdateformat=g:ia D, M j
format=<ul>,<li>[[%PAGE%|%TITLE%]]<br />%USER% - %DATE%,</li>,</ul>
noresultsheader=''None''
</dpl>
|-
! Recent Discussion
|-
|<dpl>
namespace=Talk|UE1_talk|UE2_talk|UE3_talk|Unreal_Wiki_talk|Category_talk|Legacy_talk
count=5
ordermethod=lastedit
order=descending
mode=userformat
adduser=true
addeditdate=true
userdateformat=g:ia D, M j
format=<ul>,<li>[[%PAGE%|%TITLE%]]<br />%USER% - %DATE%,</li>,</ul>
noresultsheader=''None''
</dpl>
|}
|}

Unreal Wiki talk:Task list

2008-04-25T04:07:43Z

DalinSeivewright: Added a little something.

Regarding this blurb from the project page: "Don't just copy pages from the 'Legacy:' namespace. Make them better by rewriting them in you own words, restructuring them or even approaching the topic from a different point of view." Doesn't that fly in the face of the new rules, which as I understand them are to *not* change the content unless you are the original author? Clear up this ambiguity on the project page, please. -- [[User:SuperApe|SuperApe]] 13:39 (PST) 21 April, 2008

: And while we're at it, "Establish a good topic structure - the old Unreal Wiki seriously lacked in this department". Let's be extremely clear as to how the old wiki seriously lacked structure, specifically what was missing and what to do to follow the new and improved structure. This has never really been discussed or designed, only to say, "the old way sucked". So here's the chance to outline what sucked and how to make it ... not suck. Let's see a very clear plan on the project page, please. -- [[User:SuperApe|SuperApe]] 13:44 (PST) 21 April, 2008

::Well I was kinda liking the basic proceedure thing that was starting to happen and wrote the [[Legacy:Using_The_Mod_System_In_UT2004]] according to that somewhat. Its not exactly on the standard layout though, so Im wondering what would be the way to join a list of basic procedures into one tutorials would be. Like for eg making a mutator class would be a basic thing and hello world mutator would expand on that basic procedure. Im also not sure what to bring over myself, its obvious class pages will make their way over with the new wikifier but for other pages I had alittle input with Im not even sure who the original creator was anyways. Perhaps basic procedure could be listed on this task list as well if its still the way things are going. -[[User:OlympusMons|OlympusMons]] 23:42, 21 April 2008 (UTC)

::: I personally thought the one or two tutorial series were neat. They took the user from Hello world to making a weapon in just a few short tutorials. -[[User:DalinSeivewright|DalinSeivewright]] 05:40, 22 April 2008 (UTC)

:: The old Wiki was a mess. Lengthy discussions could be found on the majority of sites pages, as well as detailed problems that had been abandonned while still being unanswered. The general layout of pages often changed from author to author and so it was sometimes difficult to find what you were looking for. The only thing about it that I truly liked was the Category layout and the UnrealScript reference. I think as a general rule we need to keep lengthy paragraphs to a minimum unless absolutely neccesary and keep things clear and straight to the point. I also believe there needs to be a standard format we need to develop and work towards, which will take some time to work out. There needs to be a useful purpose served by a given page. The old wiki had a lot of 'junk' - pages that were just a waste of space and had no clear reason for its existance.-[[User:DalinSeivewright|DalinSeivewright]] 05:40, 22 April 2008 (UTC)

::: I'm not sure how to make this any clearer: We need to outline what to *do* not what not to do. Dalin, I know you're contributing and trying to help. I'm not bashing you. I'm trying to help clarify the "the old sucked" and form a comprehensive, or at least cohesive plan of how to move forward from here. To that end, let me "translate" your last paragraph of comments into something action-able, ignoring those comments which cannot help to form the new organization plan (i.e., "The old Wiki was a mess"). 1) "Lengthy discussions could be found on the majority of sites pages" : Our discussions have now been relocated to a special Discussion tab for each page; nice and neat. 2) "detailed problems that had been abandonned while still being unanswered" : (not sure if there is anything to do except) ask all wiki users/contributors to be vigilant in responding to questions asked on various pages. (?) 3) "The general layout of pages often changed from author to author and so it was sometimes difficult to find what you were looking for." : (not sure if you mean to say that individual page format varied, or the structures of different sections of the wiki varied in organization format) Either way, the solution is again to ask wiki users to be vigilant in conforming to a set organizational structure on pages and in groups of pages. *And this is of course why* I'm turning these loose complaints into something actionable, so that an organizational structure can be developed. 4) "The old wiki had a lot of 'junk' - pages that were just a waste of space and had no clear reason for its existance." : Perhaps then this is an extra step; to evaluate new pages as they are created, and judge them for usefulness and content. This list of things I extracted from the previous paragraph boils down to: (discussion already moved), ask wiki users to be vigilant, perhaps judge content as its created, ... and that's all. This is *not* an organization plan! Does all this make sense? Avoid rantish complaints and come up with some organizational plan any wiki user can clearly follow. So far, I've been watching what's going on here and I remain wholly unconvinced that any such plan exists, and further, I doubt a comprehensive organizational plan will emerge in the near future. I don't want to see the wiki suffer and fade out of use because no one paid attention to this problem. That is why I strongly urge active contributing members to get it together, forget the past, and get an organizational structure together as soon as possible. -- [[User:SuperApe|SuperApe]] 09:03 (PST) 22 April, 2008

:::: I was merely stating my thoughts on the matter and not attempting to create an organizational plan. I was also responding to your first question about identifying what was wrong with the Wiki. Perhaps you should create a simple organizational plan yourself, post it here or somewhere on the wiki and we'll contribute and we can work towards a semi-final draft of what we're looking to see in general. My only specific organizational thoughts are on the class pages such as [[UE2:PawnFactory|Pawn Factory]] where all the variables and functions are described along with their definitions. Following that the Source code with the class hierarchy just above it. This was very similar to the class pages of most (if not all) of the old-wiki class pages. Whats semi different is that, besides the introduction section, its straight to the point. The seperation of the main page and the talk page help is a lot. -[[User:DalinSeivewright|DalinSeivewright]] 17:02, 22 April 2008 (UTC)

::::: As I have said in other discussions here on the wiki (which is another large problem here: there is no single place for discussion defined, so this organizational conversation is disjointed among several different pages), "Seeing as I was an instrumental contributor of the old organization (which has been widely criticized as poor or no organization), I will step back, keep an eye on the progress and wait for the dust to settle." That is why I'm not proposing an organizational plan myself, but that was a very good question. Hope more chime in on this topic soon. -- [[User:SuperApe|SuperApe]] 14:09 (PST) 22 April, 2008

:::::: I stumbled upon this while looking for ways to give newcomers to the Unreal Wiki more pertinent information before they start contributing: [[Unreal_Wiki:Style_guide]]. I don't think its exactly what you're looking to see, but then again its something to work off of. As for this organizational plan that you are looking to see, it isn't clear to me what you're wanting. Then again, I guess you're not clear on the new vision for this site either, so I guess you might not know what you are wanting to see. Just thought I'd 'refresh' this discussion (which could probably use some refactoring/deleting ;) ) to see if we can get others discussing this. -[[User:DalinSeivewright|DalinSeivewright]] 04:07, 25 April 2008 (UTC)

Main Page

2008-04-25T03:56:39Z

DalinSeivewright:

'''Welcome to the {{SITENAME}}.''' This site's goal is to provide comprehensive documentation of the [[Unreal Editor]], [[UnrealScript]] and all technical aspects of the [[Unreal Engine]].

If you came here as a player and are looking for details about the Unreal series of games, head over to BeyondUnreal's [[Liandri:|Liandri Archives]]. If you are a server administrator looking for information about running servers for Unreal series games, try the [[uadmin:|Unreal Admin Wiki]] instead.

{{ambox|type=serious|text=Please refrain from using an offline reader or similar tools to download the entire Unreal Wiki.

These tools put an insane stress on the server and will most likely get you banned immediately. The Unreal Wiki has a very dynamic nature, but if you want to download a recent snapshot, try our downloadable [[Project:Offline Wiki|Offline Wiki]] archive.}}

{{ambox|type=notice|text=We've recently [[Unreal Wiki:MediaWiki conversion|switched]] to the [[wp:MediaWiki|MediaWiki]] engine, and we're taking this opportunity to refresh the site's organization and content. The old content is available in full at [[Legacy:Home Page|the legacy home page]]. During this transition, you'll notice many red-colored links, which point to pages that don't yet exist. [[Project:Community Portal|See how you can help]] form the new, improved {{SITENAME}}.}}

__NOTOC__ __NOEDITSECTION__
{| cellpadding="0" cellspacing="10px" style="width:100%;"
| id="topic-list" style="vertical-align:top;" |
==Community==
The [[Project:Community Portal|Community Portal]] is the general place to find out what's going on and what needs to be done on the {{SITENAME}}.

New to the {{SITENAME}}? Feel free to join the other {{NUMBEROFUSERS}} users by [[Special:Userlogin|registering]]. The {{SITENAME}} is a community project and you are invited to [[Project:Helping out|help improve]] it. [[Project:Getting started|Getting started]] provides some tips on how to get started!

==Content==
The quickest way to find what you're looking for usually is the search box on the left. Otherwise, try one of the topical starting points below.

===General topics===
* [[Unreal Engine overview]]
* [[Modding overview]]

===Mapping reference===
* [[Unreal Editor overview]]
* [[Mapping concepts]]
* [[:Category:Mapping tutorials|Mapping tutorials]]

===UnrealScript reference===
* [[UnrealScript overview]]
* [[:Category:Classes|UnrealScript API]]
* [[:Category:Programming tutorials|UnrealScript tutorials]]

===Modeling reference===
* [[Modeling overview]]
* [[:Category:Modeling tutorials|Modeling tutorials]]

Still can't find what you were looking for? You can browse through all of the [[:Category:Article categories|articles by category]] or the [[Legacy:Home Page|old {{SITENAME}} content]].

| style="vertical-align:top;" |
{| class="infobox infobox-pages" id="recent-edits" style="width:300px;float:none;margin-left:auto;"
|-
| style="text-align:center;font-size:smaller;" |''See [[Special:Recentchanges|Recent changes]] for all changes.''
|-
! Recent Updates
|-
|<dpl>
namespace=|UE1|UE2|UE3
count=5
ordermethod=lastedit
order=descending
mode=userformat
adduser=true
addeditdate=true
userdateformat=g:ia D, M j
format=<ul>,<li>[[%PAGE%|%TITLE%]]<br />%USER% - %DATE%,</li>,</ul>
noresultsheader=''None''
</dpl>
|-
! New Pages
|-
|<dpl>
namespace=|UE1|UE2|UE3
count=5
ordermethod=firstedit
order=descending
adduser=true
addeditdate=true
userdateformat=g:ia D, M j
format=<ul>,<li>[[%PAGE%|%TITLE%]]<br />%USER% - %DATE%,</li>,</ul>
noresultsheader=''None''
</dpl>
|-
! Recent Discussion
|-
|<dpl>
namespace=Talk|UE1_talk|UE2_talk|UE3_talk|Unreal_Wiki_talk|Category_talk|Legacy_talk
count=5
ordermethod=lastedit
order=descending
mode=userformat
adduser=true
addeditdate=true
userdateformat=g:ia D, M j
format=<ul>,<li>[[%PAGE%|%TITLE%]]<br />%USER% - %DATE%,</li>,</ul>
noresultsheader=''None''
</dpl>
|}
|}

Main Page

2008-04-25T03:54:56Z

DalinSeivewright: Switched up the order of Content and Community as I believe the Community information is more important for new users to read.

'''Welcome to the {{SITENAME}}.''' This site's goal is to provide comprehensive documentation of the [[Unreal Editor]], [[UnrealScript]] and all technical aspects of the [[Unreal Engine]].

If you came here as a player and are looking for details about the Unreal series of games, head over to BeyondUnreal's [[Liandri:|Liandri Archives]]. If you are a server administrator looking for information about running servers for Unreal series games, try the [[uadmin:|Unreal Admin Wiki]] instead.

{{ambox|type=serious|text=Please refrain from using an offline reader or similar tools to download the entire Unreal Wiki.

These tools put an insane stress on the server and will most likely get you banned immediately. The Unreal Wiki has a very dynamic nature, but if you want to download a recent snapshot, try our downloadable [[Project:Offline Wiki|Offline Wiki]] archive.}}

{{ambox|type=notice|text=We've recently [[Unreal Wiki:MediaWiki conversion|switched]] to the [[wp:MediaWiki|MediaWiki]] engine, and we're taking this opportunity to refresh the site's organization and content. The old content is available in full at [[Legacy:Home Page|the legacy home page]]. During this transition, you'll notice many red-colored links, which point to pages that don't yet exist. [[Project:Community Portal|See how you can help]] form the new, improved {{SITENAME}}.}}

__NOTOC__ __NOEDITSECTION__
{| cellpadding="0" cellspacing="10px" style="width:100%;"
| id="topic-list" style="vertical-align:top;" |
==Community==
The [[Project:Community Portal|Community Portal]] is the general place to find out what's going on and what needs to be done on the {{SITENAME}}.

New to the {{SITENAME}}? Feel free to join the other {{NUMBEROFUSERS}} users by [[Special:Userlogin|registering]]. The {{SITENAME}} is a community project and you are invited to [[Project:Helping out|help improve]] it. [[Project:Getting started|Getting started]] provides some tips on how to use {{SITENAME}}.

==Content==
The quickest way to find what you're looking for usually is the search box on the left. Otherwise, try one of the topical starting points below.

===General topics===
* [[Unreal Engine overview]]
* [[Modding overview]]

===Mapping reference===
* [[Unreal Editor overview]]
* [[Mapping concepts]]
* [[:Category:Mapping tutorials|Mapping tutorials]]

===UnrealScript reference===
* [[UnrealScript overview]]
* [[:Category:Classes|UnrealScript API]]
* [[:Category:Programming tutorials|UnrealScript tutorials]]

===Modeling reference===
* [[Modeling overview]]
* [[:Category:Modeling tutorials|Modeling tutorials]]

Still can't find what you were looking for? You can browse through all of the [[:Category:Article categories|articles by category]] or the [[Legacy:Home Page|old {{SITENAME}} content]].

| style="vertical-align:top;" |
{| class="infobox infobox-pages" id="recent-edits" style="width:300px;float:none;margin-left:auto;"
|-
| style="text-align:center;font-size:smaller;" |''See [[Special:Recentchanges|Recent changes]] for all changes.''
|-
! Recent Updates
|-
|<dpl>
namespace=|UE1|UE2|UE3
count=5
ordermethod=lastedit
order=descending
mode=userformat
adduser=true
addeditdate=true
userdateformat=g:ia D, M j
format=<ul>,<li>[[%PAGE%|%TITLE%]]<br />%USER% - %DATE%,</li>,</ul>
noresultsheader=''None''
</dpl>
|-
! New Pages
|-
|<dpl>
namespace=|UE1|UE2|UE3
count=5
ordermethod=firstedit
order=descending
adduser=true
addeditdate=true
userdateformat=g:ia D, M j
format=<ul>,<li>[[%PAGE%|%TITLE%]]<br />%USER% - %DATE%,</li>,</ul>
noresultsheader=''None''
</dpl>
|-
! Recent Discussion
|-
|<dpl>
namespace=Talk|UE1_talk|UE2_talk|UE3_talk|Unreal_Wiki_talk|Category_talk|Legacy_talk
count=5
ordermethod=lastedit
order=descending
mode=userformat
adduser=true
addeditdate=true
userdateformat=g:ia D, M j
format=<ul>,<li>[[%PAGE%|%TITLE%]]<br />%USER% - %DATE%,</li>,</ul>
noresultsheader=''None''
</dpl>
|}
|}

User:DalinSeivewright

2008-04-25T03:38:52Z

DalinSeivewright:

== Info ==
*Name: Dalin Seivewright
*Nick: MythOpus
== Links ==
*[[/Developer Journal | Developer Journal]] - Newer experiences while getting back into it.
*[[/Old Developer Journal | Archived Developer Journal]] - Mostly (if not all) about my experiences with working on a custom AI derived from the Actor class.

User:DalinSeivewright

2008-04-25T03:38:35Z

DalinSeivewright:

== Info ==
*Name:Dalin Seivewright
*Nick: MythOpus
== Links ==
*[[/Developer Journal | Developer Journal]] - Newer experiences while getting back into it.
*[[/Old Developer Journal | Archived Developer Journal]] - Mostly (if not all) about my experiences with working on a custom AI derived from the Actor class.

User:DalinSeivewright

2008-04-25T03:38:23Z

DalinSeivewright:

== Info ==
*Name:Dalin Seivewright
*Nick: MythOpus
=== Links ===
*[[/Developer Journal | Developer Journal]] - Newer experiences while getting back into it.
*[[/Old Developer Journal | Archived Developer Journal]] - Mostly (if not all) about my experiences with working on a custom AI derived from the Actor class.

User:DalinSeivewright

2008-04-25T03:38:12Z

DalinSeivewright:

== Info ==
*Name:Dalin Seivewright
*Nick: MythOpus
=== Links ===
[[/Developer Journal | Developer Journal]] - Newer experiences while getting back into it.
[[/Old Developer Journal | Archived Developer Journal]] - Mostly (if not all) about my experiences with working on a custom AI derived from the Actor class.

User:DalinSeivewright/Developer Journal

2008-04-25T03:35:18Z

DalinSeivewright:

User:DalinSeivewright/Developer Journal

2008-04-25T03:31:09Z

DalinSeivewright:

__NOEDIT__
{{classbox| Welcome To Dalin Seivewright's Wiki Developer Journal.}}

This page is used by Dalin Seivewright to post his developer related thoughts, open source code, and concepts. The journal entries are on this page while the discussions for every entry are available on the [[User_talk:DalinSeivewright/Developer_Journal|discussion page]]. If you wish to to join in on the discussion or if there isn't one already started on a particular entry, feel free to start one yourself.

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----
=Journal Entries=
==Thursday, April 24th, 2008==
<span id="APRIL242008" name="APRIL242008"></span>
(placeholder)
===Entry Source Code===
<div class="hidden-block"><span class="hint">Source Code 1</span><div class="hidden">(placeholder)</div></div>
===Entry Disussion===
For discussion on this entry, please see [[User_talk:DalinSeivewright/Developer_Journal#APRIL242008|the discussion page]].

User:DalinSeivewright/Developer Journal

2008-04-25T03:30:29Z

DalinSeivewright:

{{classbox| Welcome To Dalin Seivewright's Wiki Developer Journal.}}

This page is used by Dalin Seivewright to post his developer related thoughts, open source code, and concepts. The journal entries are on this page while the discussions for every entry are available on the [[User_talk:DalinSeivewright/Developer_Journal|discussion page]]. If you wish to to join in on the discussion or if there isn't one already started on a particular entry, feel free to start one yourself.

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----
=Journal Entries=
==Thursday, April 24th, 2008==
<span id="APRIL242008" name="APRIL242008"></span>
(placeholder)
===Entry Source Code===
<div class="hidden-block"><span class="hint">Source Code 1</span><div class="hidden">(placeholder)</div></div>
===Entry Disussion===
For discussion on this entry, please see [[User_talk:DalinSeivewright/Developer_Journal#APRIL242008|the discussion page]].

User talk:DalinSeivewright/Developer Journal

2008-04-25T03:25:21Z

DalinSeivewright: Replacing page with '==Thursday, April 24th, 2008== <span id="APRIL242008" name="APRIL242008"></span> The following is the entry discussion for [[User:DalinSeivewright/Developer_Journal#APRIL242008...'

==Thursday, April 24th, 2008==
<span id="APRIL242008" name="APRIL242008"></span>
The following is the entry discussion for [[User:DalinSeivewright/Developer_Journal#APRIL242008|Thursday, April 24th, 2008]].

User:DalinSeivewright/Developer Journal

2008-04-25T03:24:28Z

DalinSeivewright:

{{classbox| Welcome To MythOpus' Wiki Developer Journal.}}

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----
=Journal Entries=
==Thursday, April 24th, 2008==
<span id="APRIL242008" name="APRIL242008"></span>
(placeholder)
===Entry Source Code===
<div class="hidden-block"><span class="hint">Source Code 1</span><div class="hidden">(placeholder)</div></div>
===Entry Disussion===
For discussion on this entry, please see [[User_talk:DalinSeivewright/Developer_Journal#APRIL242008|the discussion page]].

User talk:DalinSeivewright/Developer Journal

2008-04-25T03:23:32Z

DalinSeivewright:

==TESTER==
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

v
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

vTesting the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.
Testing the Wiki inter-tagging html system lol lol lol...
Yeah that was bad.
The rest is just spam to lengthen the page. I take that back. Everything under this heading is just useless and will be removed.

==Thursday, April 24th, 2008==
<span id="APRIL242008" name="APRIL242008"></span>

User talk:DalinSeivewright/Developer Journal

2008-04-25T03:23:19Z

DalinSeivewright:

User talk:DalinSeivewright/Developer Journal

2008-04-25T03:23:01Z

DalinSeivewright:

User talk:DalinSeivewright/Developer Journal

2008-04-25T03:21:36Z

DalinSeivewright: New page: ==Thursday, April 24th, 2008== <span id="APRIL242008" name="APRIL242008"></span>

==Thursday, April 24th, 2008==
<span id="APRIL242008" name="APRIL242008"></span>

User:DalinSeivewright/Developer Journal

2008-04-25T03:20:30Z

DalinSeivewright:

{{classbox| Welcome To MythOpus' Wiki Developer Journal.}}

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----
=Journal Entries=
==Thursday, April 24th, 2008==
(placeholder)
===Entry Source Code===
<div class="hidden-block"><span class="hint">Source Code 1</span><div class="hidden">(placeholder)</div></div>
===Entry Disussion===
For discussion on this entry, please see [[User_talk:DalinSeivewright/Developer_Journal#APRIL242008|the discussion page]].

User:DalinSeivewright/Developer Journal

2008-04-25T03:20:02Z

DalinSeivewright:

{{classbox| Welcome To MythOpus' Wiki Developer Journal.}}

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----
=Journal Entries=
==Thursday, April 24th, 2008==
(placeholder)
===Entry Source Code===
<div class="hidden-block"><span class="hint">Source Code 1</span><div class="hidden">(placeholder)</div></div>
===Entry Disussion===
<div class="hidden-block"><span class="hint">Thursday, April 24th, 2008 </span><div class="hidden">For discussion on this entry, please see [[User_talk:DalinSeivewright/Developer_Journal#APRIL242008|the discussion page]].</div></div>

User:DalinSeivewright/Developer Journal

2008-04-25T03:18:06Z

DalinSeivewright:

{{classbox| Welcome To MythOpus' Wiki Developer Journal.}}

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----
=Journal Entries=
==Thursday, April 24th, 2008==
(placeholder)
===Entry Source Code===
<div class="hidden-block"><span class="hint"></span><div class="hidden">(placeholder)</div></div>
===Entry Disussion===
<div class="hidden-block"><span class="hint"></span><div class="hidden">For discussion on this entry, please see [[User_talk:DalinSeivewright/Developer_Journal#APRIL242008|the discussion page]].</div></div>

User:DalinSeivewright/Developer Journal

2008-04-25T03:17:24Z

DalinSeivewright:

{{classbox| Welcome To MythOpus' Wiki Developer Journal.}}

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----
=Journal Entries=
==Thursday, April 24th, 2008==
(placeholder)
===Entry Source Code===
<div class="hidden-block"><span class="hint"></span><div class="hidden">(placeholder)</div>
===Entry Disussion===
<div class="hidden-block"><span class="hint"></span><div class="hidden">For discussion on this entry, please see [[User_talk:DalinSeivewright/Developer_Journal#APRIL242008|the discussion page]].</div>

User:DalinSeivewright/Developer Journal

2008-04-25T03:14:13Z

DalinSeivewright:

User:DalinSeivewright/Developer Journal

2008-04-25T03:14:04Z

DalinSeivewright:

{{classbox| Welcome To MythOpus' Wiki Developer Journal.}}

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----
=Journal Entries=
==Thursday, April 24th, 2008
(placeholder)

User:DalinSeivewright/Old Developer Journal

2008-04-25T03:12:39Z

DalinSeivewright:

{{classbox| Welcome To Dalin Seivewright's (Archived) Developer Journal.}}

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----

=Journal Entries=

==January 26th, 08==

Mmm. Happy Late (x30) New Years. I'm not sure if I mentioned it but I'm back in school again. Since January 7th to be exact. I'm not sure how I feel about it but anyways.

I haven't touched UnrealScript since then. As common for me as that is, I'm kind of dissapointed with myself. Again. In fact, it doesn't look like I'll be working on a major OR minor UnrealScript project for awhile. I did play a decent flash-based 2d game last night though. It was called Smiley Wars, and while the gameplay itself wasn't all that fun, the idea behind it (minus the Smiley's) was a decent one. Games like it have been done before, even multiplayer ones, but this one had a map editor which sparked interest in the first place. Anyways, this game is a Deathmatch game based on 'levels' built on triangles as well as other non-collision objects. Anyways, the map editor wasn't the greatest thing in the world but it got the job done and let you create semi-awesome levels, given the restrictions of the engine itself.

So given that my 'first' language is UnrealScript I tend to prefer writing even pseudo code in UScript form and I've been toying with creating a 2D game like that... except of course with a big more features and a speed boost. Given that I hate working with Flash, I don't know enough of Java, and I don't have my VBasic editor anymore, I'm going to have to work up a concept in UScript form, which will be fun. I don't imagine anything workable coming out of it but we'll see. I may switch to a different language later on.

There's one thing I sort of despise about UnrealScript though. The process for making even the smallest mutator seems to take forever and includes several steps. I think thats one factor associated with me stopping certain projects. You need to make a folder with the name of your package, then within that a folder called classes. Then if you're making a new Gametype you need to find the appropriate GameType to extend, ovveride the appropriate functions (which could take awhile to do if you want certain functionality excluded while keeping certain functionality dependent on the previously excluded functionality. Then comes the default properties which you need to change, at the very least with the Game Name and Description. More so if you're going to be using custom maps, custom pawns, player controllers and AI controllers. Further more in your custom classes, you need to ovveride certain functions and default properties in them.

So, IMO, its just a big huge mess. I haven't touched UT3 yet, fearing that it would be even more of a task. I don't use an IDE either mind you, but thats only because I find most of the IDE's I've tried to be a tad too 'messy'. The only think I code with is UCC and ConText.

At any rate, you might end up seeing my concept ideas on this page from time to time. Anywhere from "I wonder how to do that" to "This is concept code. I'm putting it up here but please don't explicitly steal with like those Flash-game fan boys out there."

That is all.

==Monday, December 24th, 07==

Merry Christmas, first of all if I haven't said it already. Last night was my first normal sleep since I've quit my job. Previously its just been getting up at 12-4 pm, going to sleep at 8 am, and that has really thrown my sleep pattern off and I think I've been getting slightly unhealthy due to it. This week is filled with Christmas supper and what not, so it will be good. I won't be getting very many presents. Not that it truly matters to me (Two christmas' ago, I stated that I want nothing to do with Christmas presents any longer but sure enough I've still be getting a few). I've been mostly playing Guild Wars (which for some reason since Factions came out I have been wanting to buy all of the Campaigns and what not but haven't really 'gotten' into it until a couple of weeks ago. Now I'm actually concerned with how my 'build' fares. Previously, I found all of the talk of 'builds' and such to be annoying and contrary to the intent of the game. I was wrong.

Anyways, I've decided that I need to start from the beginning and go back to the only gametype I've ever released. At that time it was basically just copy and pasted code from Invasion with workarounds to support two teams that battled out for the most points. Unfortunately, I decided that it would be 'cool' to add an option to set the default player health. I had the health value set in my .ini and I didn't give it a second though until after I released it. At this time I had deleted my config and realized that whenever I tried to play a game of Team Invasion, I would not be able to move and shortly after the game would crash. This is when I realized that setting a players health to 0 without killing them is a really bad thing. The default value to set the health at was at 0 and so, if anyone picked up the gametype and didn't see the config option, they would mostly pass it off as a bugged crappy gametype.

I did fix this bug but had problems uploading it to Fileplanet and so, I gave up on it. Shortly after that, I had a hard drive failure and all of it was gone anyways. I have attempted to remake the gametype (and this time from scratch using my own code and so fourth) but every time I did so I stopped working on it because of boredom, as I've already made something like it. I'm making another attempt at it. The note to self was to remember to make a portable warp portal system, similar to the Phase Gates in natural-selection complete with a location menu. So, you would only be able to place once warp portal per zone (per team of course) and when you used said warp portal a selection menu (like the 'v' menu in ut) and it would give you a list of the zones you can warp to that have active warp portals in them. The warp portals can be destroyed. I was thinking these would be cool for larger maps but I'm not sure how useful they would be for a round of team invasion, so I would have to make some sort of strategic signifigance for them as most DM maps aren't very big and using CTF/BR maps doesn't make very much sense as the monsters would spawn on both teams side so there would be no point to kill the players on the opposite team because both teams would still get just as many kills.

That gets me thinking too. In the first iteration of Team Invasion, players could kill monsters and the players on the other team. The point of which was to get big points for killing monsters and getting the other team out of an area with lots of monsters so your own team can get the points for killing them. However, when you died you respawned instantly so you could get back to the spot you were killed at relatively quickly. I guess I'll have to put in a respawn timer like Assault has. I guess that also creates a strategic signifigance for warp portals. Hmph. Food for thought I suppose.

==Tuesday, December 11th, 07==

Oh boy. Its been awhile hasn't it. I can safely say that I have made zero progress on Icarus. In fact, after moving into the new house and getting settled, I figured it would be a great idea to start working on it again. After opening it up in my text editor, and looking through the code, I decided against it. So Icarus is yet another project dedicated to the learning side of things. I did however, start working on something similar to the project I started with. This time I have an actual mouse driven hud thats works though and that I can use to scroll around a given map. What I'm trying to do is use the mouse to place objects on the map. That part works alright, but so far I haven't been able to line up the mouse with the object properly. In fact, what I thought was a flaw in the code, is actually how it would look in real life.

That is, when the mouse is in the center of the screen (and the camera to the level is about 2000 UU's above the object you want to place) then the object appears directly under the mouse. However, when you move the mouse further from the center, the mouse and object no longer line up. I haven't the slightest of ideas on how to 'fix' this 'problem' but it makes placing structures fairly annoying when the object isn't where your mouse is. My problem is that the mouse is drawn on the Canvas and is completely different from a vector. I have the location of the mouse in vector form but that doesn't help me much seeing as the mouse is already drawn on screen and I wouldn't know how to make the neccesary changes to the position of the mouse so that it is always on the object.

Meh. I'll figure it out eventually. Or just stick to a mouse driven 'hero' that'll save the day.

==Saturday, September 29th, 07==

I've hit another snag. This one can neither be avoided or reworked. My laptop I've found out, has a video card that doesn't really support UT2004. Its sort of funny actually and mostly visible from within the editor which is primarily the problem. When you go 'outside' of the map in UED, the walls are supposed to cut away. It seems that when I zoom out, the walls do not cut-away and appear as solid walls that you can't see through. I can work around this, to an extent, but there are other twerks with it that cause the most problems, add to the fact that A. this IS a laptop and B. the monitor on THIS laptop DOES suck for level editing... Then theres the apparent lack of FPS that I seem to get whenever I look at something that would be rendered. Looking into the sky with nothing in your LOS blocking your vision from the skybox gives you roughly 60 fps (which is great, my desktop does less) but as soon as you look at anything else it drops down to 10-20 FPS which isn't fun for A. Online play, B. AI Testing, C. Level Testing or D. Any fun. I haven't really noticed this before unfortunately is because most of my testing has been done on my desktop anyways. This is a problem because the ideas I've had would require 90% of it to be done within levels due to either custom actors that need to be set up or levels in general that require the sort of environment I'm looking for. I really don't think I'm going to be getting any work done, at least not for awhile. I'm living in my Aunties spare bedroom until we find a new house and I still need to find room for my desktop. I really need it setup, at least long enough so I can get some files I need off of it. In the meantime... well... I'll be playing F.E.A.R. (which runs quite well, while UT2004 does not....) and I recently lamed out and bought myself Pokemon Diamond... Don't ask. In fact, I'm reminded of why I quit playing Pokemon. The new Zelda is coming out Tuesday though. This boy is excited.

==Tuesday, September 25th, 07==

I'm moving out of my house on either Wednesday or Thursday and frustration with that fact and various other things has the result of not that much work getting done on this project. My main computer has been decomissioned until I move into this new house (which of course, I don't know what new house I'll be getting...). That puts a serious hamper on my creative juice because most of the things that would inspire me are not on this laptop.

This AI project has frustrated me a lot though, as you may know. I've taken various breaks that have helped a lot, for example, working on a level that for now I am quite satisfied with, at least when I put into perspective my actual skill with regards to level designing. I think the main problem I have is being able to visualize everything wonderfully but I still don't have the technical skills to put it out there. I'm okay with that, my skill has improved a lot since my days of Unreal level designing, which in case you were wondering, were much more fun but a lot less 'beautiful'.

I guess the major issue with this AI project is my need to do things my way. Not saying that doing things 'my' or 'your' way is completely wrong, but if you're looking for compatibility well, then it usually is. My desire to sub-class directly from actor has led to more than one complication. For one, I can't really use any of the movement code inherent in classes like Pawn. Any game related things like death/score/etc look for a Pawn or a Controller, both of which I do not have, to set things up. Not to mention I have to re-invent the wheel even more by mimicking the way the Pawn works so my bots don't do anything that players cannot, like jumping with a z-velocity of 512 rather than 340, or jumping from a really high tower and surviving when normally you would die. Sometimes its easy to do this, sometimes its not so easy.

That being said, it leaves me Three (3) options.

The first, is to keep chugging along like I have been this past couple of months and continue for what most likely will be 6+ months of work, all of which I could have avoided by subclassing the appropriate things and spending a month of overriding and bug fixing.

The second, is to stop work on the AI all together.

The third is to start from scratch and subclass class X,Y,Z as I need them, and use states, like apprently, any sane one would do.

But wait! There is a fourth option! Yes a fourth option. What is this fourth option you ask? Well, it involves having to add/take away X amount of code from the existing code. It involves not hooking into the existing game but rather creating a new Gametype entirely. It will eventually involve faking the Spider physics type. No I won't be making a Spiderman mod.

Actually, I don't know exactly what I'll be doing. I had my heart set on something like Invasion/Alien Swarm, but that can change at any time. I think the AI the way it is now is much more fitting for something like this, aliens/creatures/monsters/ownageness. I had the image of a couple of aliens jumping on and from walls and stuff as the player runs through the hall way and as he's leaving the hall way he notices a gas line on the walls and he dives, turns and shoots the gas line, igniting the baddies. It would resemble a 'sci-fi horror' flick. I also had images of you opening a door and a monster jumping out at you only to disentigrate akin to F.E.A.R. I don't know, its all just musings right now really. I'm going to see if I can fire up my Desktop at my temporary home to get my map and all my files off of it so I will be able to finish that first while I do up some concept stuff for this idea. It really would be a great implementation for the AI in its current state.

==Thursday, September 13, 07==

Goal #1 is completed. I just set the physics to Phys_Walking in the Landed function. I forsee needing that function for other things as well. Instead of moving on to Goal #2, I think I may skip to implementing some jumping, dodging and some random 'logic' stuff.

==Wednesday, September 11, 07==

A few minor, but important things I've discovered. Firstly, there is little to no difference between how Epic gets their pawns moving and how I'm getting my bot moving. I found this out by restricting movement of my bot to only the X axis and sure enough, its Veloctiy and my own Velocity were both 440. So the bot wasn't moving too fast, the animation rate was just too fast and I don't really have anything significant in my test maps to determine how fast its moving. I fired up CTF-FaceClassic and everything looked okay. Secondly, apparently, my bots don't really want to spawn at the exactly location of the PlayerStart. I haven't looked into the cause of this, but something tells me when bots spawn inside the flag room (in Face, PlayerStarts are only outside behind either tower).......

Forget point two. The reason they don't spawn on the playerstarts is beacuse they are being spawned on NavigationPoints so... My bad. On to point number two again though... The design of my previous mod idea has come back to haunt me again. I didn't implement any z-axis movement at all into the bot so its kind of funny to watch them go over the edge in Face, only to hover and move around in circles until they stop. At which point, the fall until they start moving again. The falling down part is probably the native physics taking hold. Anyways, I'll need to work on that part before I do anything else really. I'm also required to work on and finish the weapon firing code. Its basically just a mess of test code that allows the bots to fire through walls and what not. I suppose I'll just make a nice list to keep me on track:
# Implement Z-Axis movement. (I.E. Getting the bot to fall when it needs to fall...)
# Create '''actual''' weapon firing code.
# Get RotationSmoothing to be randomized within a Min and Max value. (To make aiming more realistic-ish)
# Implement some jumping action so the bot can have fun.
# Implement some sort of "ignore player until it makes me angry" random logic. So that the bot doesn't appear to only aim for the players all the time. Current the bot will just aim at you all the time and move toward you and shoot you. This behavior has "...got to go!"
# Implement some dodging.
# Re-implement squad tactics and objectives seeking etc.
# Tweak. Tweak. Then more Tweaking.

I'm beginning to wonder if the ideas I have for making the bot seem more real are going backfire on me. If the aiming setup I have now makes the bot Aim with fairly good accuracy then I'm probably going to have to through in some random directions to face every once in awhile and randomize the aiming restrictions a bit more.

'''Edit:''' And I forget to add the fact that I need to put in some aiming code for the Z-Axis too. Currently the bot can only aim and fire along one plane, that being the X+Y plane.

==Saturday, September 08, 07==

After thinking about interfacing the weapons from UT into my AI, I decided that it would be best to just have it simulate an InstaGib shock rifle, as thats my favorite weapon and gameplay. I've come to a blockade though. I've always assumed that what drove a Pawn to move in direction A was simply something like this: Velocity = vector(Rotation) * GroundSpeed. In reality, it seems much more complex than that. My AI's walking speed was set to something like 100. Realizing the great differences between my (well, my pawns) ability to walk, and its ability to walk, I decided to make the basic movement values the same. So, the AI and the Pawn have walking speeds of 440. Well, my happiness came to a crashing halt. My AI moved 10x faster than I did. After looking into both Controller classes and Pawn classes, and after experimenting with what I saw, I can safely say that I have no idea how Pawns get their movement done. Why couldn't they have just done the previously shown code? I had a great remembrance that the Pawns have Karma Physics working with them. I thought perhaps this created friction so instead of going 100 miles an our, it slowed them down considerably. I was wrong, it seems. I think I'm in for another month of trying to work this out, and then have someone come along and give me a solution. Would that be beneficial to me or not? I don't know.

I even subclassed Pawn instead of Actor. What I got was a lot of hellish rotation and zero movement, regardless of how many functions I overwrote.

==Wednesday, September 05, 07==

Not that much progress at all except for the fact that I've found a decent way to get the AI to use normal weapons without having to make my own. UTRPG has a base weapons class that has a 'Modified Weapon' that it controls. So, if the base weapon were controlling a shock rifle, all of the functions of the shock rifle would be called whenever the appropriate function is called on the base weapon. So function startfire would call startfire on the modified weapon. I suppose I will most likely do it similar to that except I'll have to overide a few things from the controlled weapons for the new aiming system. Hmph.

==Sunday, September 02, 07==

So I'm sitting here at 3:21 AM. I work at 10:30 AM. Before bed, I decide to take one last look at my code to see if I could find anything that I haven't noticed which would be making things difficult for the aiming code. The AI turned perfectly when doing normal rotations but as soon as it was told to aim at me, it rotated stupidly. I knew it would be something small and hard to notice, but I didn't know until now. I assumed the problem lie in my helper functions which added or subtracted a rotation based on some value. While going about it this way I fixed a few problems with the code that I didn't think about. For example, what happens when my rotational code is passed a negative yaw value. When I first encountered this problem, I just thought a nice small absolute function would fix it. I didn't think about the problems that would have though because the -90 degrees is not the same as +90 degrees so and absolute value would make 270 degrees equal to 90 degrees (which means the rotation from the -Yaw value passed will give a mirrored resulting rotation... -90 degrees = 270 degrees but the AI would rotate to 90 degres). [end incoherent rambling]. I added a little bit to fix that, so that problem resolved, but another problem occured when the AI wasn't rotation in the right direction. I knew it couldn't have been any of the rotational code that decided what way the AI should turn because as I said, when the bot isn't aiming, it rotates just fine.

I like to ramble, sorry... the solution for my aiming problem was quite simple. And, I'll even share it with all of you.

<uscript>
bTurnDirSet = False;
//aim code here
</uscript>

I had forgotten that after the AI decides what way it should turn to reach it wanted rotation, I set bTurnDirSet to true so the AI won't keep trying to calculate a new turning direction. Because after every tick the bot tries to aim at the player, bTurnDirSet is always true because unless the bot stops moving, its not set to false so the AI doesn't recalculate its turning direction. Well, now its fixed.

Now the only problem is... interfacing weapons... and moving to a new house soon. Hmph.

==Monday, August 27, 07==

Not much progress has been made since last update, for various reasons.

1. I have no idea what I'll be doing in the future with regards to my life. I had planned on going to school still and just continuing to work at my current job or get a new job working in an area that I'm more suited for. Neither of those plans are looking to good for me.

2. AI Aiming code. I have all of the neccesary components. The bot is supposed to aim at the player. When the bot has rotated to the rotation with which it will use to fire a shot (hopefully hitting the player, for the AI's sake). The code looks great and is implemented into the movement code. The hitch is, it doesn't work.

Well actually, thats not true. The AI DOES rotate and when its within a certain radius it DOES shoot a beam... but it doesn't rotate or shoot in the direction of the player. I have it set up where the player is always this bots target and when it comes within 1024 UU's of its target it starts to 'aim' at the player. When the player comes within 256 uu's the bot starts firing at the player. When the player is within range of either, the AI goes stupid and instead of rotating properly it decides that its going to take 2 hours to rotate to one direction (often passing that direction). When I implemented this and saw this behavior, I was worried that I had broken my rotational code (again!x5) but I observed that when I went out of the aiming range, the bot started to make its own rotational choices and rotated to said rotations normally. So, I didn't break the rotational code... thats great... the Aiming code however evidently needs to be rebuilt.

3. I'm thinking about how I can get the bots to use the existing weapons in game. The problem you ask? The weapons are basically hardcoded to use Epics class tree and methods. Why is this a problem? Why don't I just remake my own weapons? Are you kidding? Remaking all of the existing weapons would be a horrible decision. This is a fairly simple custom bot and with it, it shouldn't need to use custom weapons that do exactly the same thing as the default weapons. I suppose I could just revert back to my plan for making a mod but I don't like that Idea. I need to somehow make an interface between my bot and the current weapons in UT. That also has its own problems. AimError. Eek.

4. Depression. Depression caused by all of the above and probably more. I'm just really bored and have nothing to do. Its a shame... I waste all of my free time.

Anyways, I'll probably rip out the aiming code and do a rewrite of it (again!) and hopefully by the time I move, it will be working.

==Tuesday, August 21, 07==

EricBlade expressed an interest in my AI movement code, so here it is. Keep in mind there are probably several optimization that could be made. Also keep in mind that its basically a rip out of my current AI code which also includes other things. As a result the way I have done some things probably isn't very clear. Some function names could be a bit more, clear, but I've commented on parts that I thought I might need to. This is by no means a final version of the movement code. Things will no doubt be taken out, added or changed. If this breaks you, your computer or anyone else, its not my fault. Also Note, my AI class is directly extended from Actor so I wouldn't have to use a lot of Function overrides and deal with a lot of stupid code. If you use this in any code that does extend from another class, you may need to work it in properly. Have fun. Modify it as you see wish but please give Credit Where It Is Due. When the AI is actually done, I will be releasing it as Open Source anyways so don't do anything stupid :D

'''Update:''' The following code already got a switch up. I'm now in the process of adding rotational code for 3D rather then the 2D stuff leftover from the mod project I was working on which started this whole AI sharade. Also...

Note: The following code only works with the Yaw component of a rotator. Pitch and Roll are excluded from this. Sorry. Wait till release I suppose.

<div class="hidden-block"><span class="hint">Current AI Movement Iteration</span><div class="hidden">
<uscript>
class DS_AIMovement extends Actor;

//Moving System
var bool bMoving; //Is the AI moving?
var bool bStopped; //True when the AI has stopped and is waiting.
var int MovingTime; //The current time left for moving. INTERNAL
var int WaitingTime; //The current time left for waiting. INTERNAL
var vector LastLocation; //The location the AI was at on the last tick.

var bool bWaitTimeSet;
var int MinMovingTime; //Minimum value for the movement time.
var int MaxMovingTime; //Maximum value for the movement time.
var int MinWaitingTime; //Minimum value for the waiting time.
var int MaxWaitingTime; //Maximum value for the waiting time.

var float WalkingSpeed; //The speed used when the AI is walking...
var float CurrentSpeed; //The current movement speed

//Rotation System
var bool bTurnDirSet; //Has the turn direction been chosen?
var int TurnDir; //Direction AI has chosen to turn. 0 - Clockwise 1 - Counter Clockwise
var int RotationSmoothing; //How fast does the AI turn
var int RotationLimit; //How much difference can there be between the AI's Current rotation
//And its Desired rotation
var float DesiredYaw, CurrentYaw; //Desired rotation and current rotation

/*
General Function Section
*/

function PostBeginPlay()
{
//Start with random rotation
CurrentYaw = rand(65536);
SetRotation( SetUpRotator(CurrentYaw) );

MovingTime = Rand(MaxMovingTime - MinMovingTime);
MovingTime = MovingTime + MinMovingTime;

}

function Tick(float DeltaTime)
{
AINonCombat(DeltaTime); //Handles movement and interactivity with the game world when engaged in combat
}

/*
Movement Function Section
*/

/*
Function AINonCombat
Paremeter 1: Type - Float Name - DeltaTime
This function gets the movement all set up and going.
*/
function AINonCombat(float DeltaTime)
{
//While NOT Moving
if( !bMoving )
{
//Note: See notes in the Function Description!!
AIDecideDirection(); //Deciding Direction To Go In

AIStartMove(); //Starting To Move In Decided Direction
}
//While Moving
else
{
AIPreventBlockedMovement(); //If The AI Is Blocked, We Need To Try And Unblock Him
AIDecideTurnDirection(); //Decide Which Way The AI Should Turn To Get To Direction
AIStartRotateProcess(); //Start Rotating To Decided Direction

if( !bStopped )
AIUpdateMovement(); //Updating Velocity And What Not

AIUpdateMovementTimer(); //Updating Movement Timer
}
}

/*
Function AIDecideDirection
Decides what direction it wants to go on
based on its CurrentDirection.
I.E. If RotationLimit is 8192 (45 degrees)
the bot will have a limit to rotate 45 degrees on either side
of its CurrentYaw. So in this case, if the bots
CurrentYaw is 90 degrees, it would only be able to rotate
to anywhere between 45 degrees and 135 degrees.

As an alternative to this system, you can use
AIDecideDirectionOLD. There is no restriction
of where the AI can go with that function.
*/
function AIDecideDirection()
{
local float f; //Decides How Much We Turn
local int NYaw; //The angle to add or subtract

f = fRand() * 2; //Gives us a float between 0 and 2.
NYaw = f * RotationLimit; //Gives us a yaw value between 0 and RotationLimit to add or subtract

if( f < 1 )
//We subtract NYaw from CurrentYaw
DesiredYaw = OperationWithAngle(CurrentYaw, NYaw, False);
else if( f > 1 )
//We add NYaw to CurrentYaw
DesiredYaw = OperationWithAngle(CurrentYaw, NYaw, True);
else
//We do nothing to the CurrentYaw
DesiredYaw = CurrentYaw;
}

/*
Function AIDecideDirectionOLD
Decides what direction it wants to go on.
This new direction could be anywhere between
0 and 65535 (0 to 360).
*/
function AIDecideDirectionOLD()
{
DesiredYaw = Rand(65536);
}

/*
Function AIStartMove()
This function will get that AI moving in its inital rotation and velocity.
It will also start any animations needed.
*/
function AIStartMove()
{
CurrentSpeed = WalkingSpeed;
SetRotation( SetupRotator( CurrentYaw ) );
Velocity = vector(Rotation) * CurrentSpeed;
LoopAnim('WalkF');
bTurnDirSet = False;
bMoving = True;

}

/*
Function AIPreventBlockedMovement
This tells the AI to stop moving if they're being blocked.
TODO: Instead of just stopping the AI, get it to choose another direction to go in.
*/
function AIPreventBlockedMovement()
{
//If the pawn has stopped moving and they haven't chosen to stop
//i.e. they're being blocked by something.
if( !bStopped && (Location == LastLocation) )
{
LoopAnim('Idle_Rest');
bTurnDirSet = False;
bMoving = False;
}
}

/*
Function AIDecideTurnDirection
This function, based on the desired direction, determines which way
the AI should turn to get to its DesiredYaw faster.
For example, if the AI is facing 45 degrees and it wants to face 90 degrees
it would be faster to rotate counter-clockwise then to rotate clockwise.

Note: A great many thanks goes to everyone who tried to help me figure this part out
especially EricBlade from the UWiki who actually figured out the right thing to do.
*/
function AIDecideTurnDirection()
{
local rotator A;

if( !bTurnDirSet )
{
A = Normalize( SetupRotator(CurrentYaw) - SetupRotator(DesiredYaw) );

if( A.Yaw > 0 )
TurnDir = 1; //Counter-Clockwise
else
TurnDir = 0; //Clockwise

bTurnDirSet = True;
}
}

/*
Function AIStartRotateProcess
This function gets the AI rotating the
desired way to the desired direction
*/
function AIStartRotateProcess()
{
//If we've set the turning direction and the AI is not standing still
if( bTurnDirSet && CurrentYaw != DesiredYaw)
{
//If TurnDir is 0 (clockwise)
if( TurnDir == 0 )
{
//If CurrentYaw is greater or equal to 65535 (360)
//Then set it to 0 so we can continue
if( CurrentYaw >= 65535 )
CurrentYaw = 0;

//If CurrentYaw is less than DesiredYaw we need to add to
//CurrentYaw to reach the DesiredYaw.
if( CurrentYaw < DesiredYaw)
//128 is divisible by 8192 (our lowest set yaw value)
//Finding the minimum between CurrentYaw + 128 and DesiredYaw.
//CurrentYaw + 128 will always be chosen until CurrentYaw equals
//or is greater than DesriedYaw.
CurrentYaw = FMin( CurrentYaw + 64*RotationSmoothing, DesiredYaw );
else
//Here we need to find the max because if we get here
//it means that CurrentYaw is greater then Desired yaw but
//We still need to add 128 because we're still going clockwise.
//For example if we're at 315 (45 degrees in real life) and we want to get
//To 45 degrees (315 in real life... remember, the axis' are inverted) then
//we would have to keep adding to CurrentYaw until it gets to 65535 (360 degrees)
//At which point it will be set to 0 and we can continue adding until we reach the DesiredYaw.
CurrentYaw = FMax( CurrentYaw + 64*RotationSmoothing, DesiredYaw );
}
else if( TurnDir == 1 )
{
//If CurrentYaw is less or equal to 0 then
//Set CurrentYaw to 65535 (360)
if( CurrentYaw <= 0 )
CurrentYaw = 65535;

//If CurrentYaw is less than DesiredYaw and CurrentYaw does not equal Zero -FIX ME
if( CurrentYaw < DesiredYaw && CurrentYaw != 0)
//We need to find the minimum value between CurrentYaw - 128 and DesiredYaw.
//We are going counter-clockwise so CurrentYaw - 128 will always be the min value,
//until CurrentYaw is equal or lesser than DesiredYaw.
CurrentYaw = FMin( CurrentYaw - 64*RotationSmoothing, DesiredYaw );
else
//Here we need to finx the Max between the two values because
//We've flipped over 0 and started at 65535
CurrentYaw = FMax( CurrentYaw - 64*RotationSmoothing, DesiredYaw );
}
}
}

/*
Function AIUpdateMovement
Updates rotation and velocity
TODO: Merge with a similar function.
*/
function AIUpdateMovement()
{
SetRotation( SetupRotator( CurrentYaw ) );
Velocity = vector(Rotation) * CurrentSpeed;
}

/*
Function AIUpdateMovement
This function updates the time the AI has left to move.
Also: Decides if there will be a wait time and then updates
that as well.
*/
function AIUpdateMovementTimer()
{
local int iTempHold; //Decides whether we Wait at the end
iTempHold = Rand(5);
//If the AI's moving time is over
if( MovingTime == 0 )
{
bTurnDirSet=False; //We don't know what way we're going to turn so we need to reset that
//Since the moving time is 0 we can... START THE ADDITIONAL WAIT! YAY!

//Setup for the additional wait
if( !bWaitTimeSet )
{
AIStopMovement();
WaitingTime = Rand(MaxWaitingTime - MinWaitingTime);
WaitingTime = WaitingTime + MinWaitingTime;
bWaitTimeSet = True;
}

if( WaitingTime != 0 )
{
WaitingTime--;
}

if( WaitingTime == 0 )
{
//Since the moving time is 0 we can...
//If he's not standing still then reset the moving time for the
//next move. If the AI IS standing still, then MovingTime will
//Use the Waiting Min and Max. Which will be set in the AIStartMove() function.

//Finding the max time it will be.
MovingTime = Rand(MaxMovingTime - MinMovingTime);
//Adding the minimum time to move.
MovingTime = MovingTime + MinMovingTime;

LastLocation = Location;
bWaitTimeSet = False;
bMoving = False; //The AI isn't moving anymore.
bStopped = False;
}

}
else
//If MovingTime isn't 0 then we can keep subracting from it.
//It IS a Moving counter after all.
MovingTime--;
}

/*
Function AIStopMovement
Orders a full stop of the AI.
*/
function AIStopMovement()
{
bStopped = True;
LoopAnim('Idle_Rest');
Velocity = vect(0,0,0);
}

/*
HELPER FUNCTIONS
*/

//Helper Function - Returns a rotator with a Yaw
simulated function rotator SetupRotator(float Yaw)
{
local rotator NewRotation;
NewRotation.Pitch = 0;
NewRotation.Roll = 0;
NewRotation.Yaw = Yaw;
return NewRotation;
}

//Helper Function - Returns a rotator with a Yaw, Roll and Pitch
simulated function rotator SetupSpecialRotator(float Roll, float Pitch, float Yaw)
{
local rotator NewRotation;
NewRotation.Roll = Roll;
NewRotation.Pitch = Pitch;
NewRotation.Yaw = Yaw;
return NewRotation;
}

//Helper Function - Returns opposite angle of A
function int Add180(int A)
{
local int NewAngle;
A = Abs( A );
NewAngle = 32768 + A;
if( NewAngle > 65535 )
NewAngle = NewAngle - 65535;
if( NewAngle == 65535 )
NewAngle = 0;
else if( NewAngle == 0 )
{
NewAngle = 65535;
}
return NewAngle;
}

//Helper Function - Keeps Angles within 0 to 65535...
function int TrimYaw(int A)
{
//Using the Bitwise might work, but I haven't
//Been able to do this properly with it
A = abs( A );
while( A > 65535 )
A = A - 65535;

return A;
}

//Helper Function - Adds or Subtracts Integer B from Integer A
// and keeps it within 0 to 65535..
function int OperationWithAngle(int A, int B, bool bAddition)
{
local int i;
if( bAddition )
{
i = A + B;
i = TrimYaw(i);
return i;
}
i = A - B;

if( i < 0 )
i = 65536 - abs(i);

return i;

}

DefaultProperties
{
// default everything to ThunderCrash.Jakob
Mesh=Mesh'ThunderCrash.JakobM'
Skins(0)=Texture'DemoPlayerSkins.Jakob_Body'
Skins(1)=Texture'DemoPlayerSkins.Jakob_NewHead'
DrawType=DT_Mesh
Style=STY_Normal
bMovable=True
Physics=PHYS_Walking
bCollideWorld=True
bCollideActors=true
bBlockActors = True
MinMovingTime=2000
MaxMovingTime=2250
MinWaitingTime=500
MaxWaitingTime=2000
WalkingSpeed=100
RotationSmoothing = 1
RotationLimit = 8192
}
</uscript></div></div>

==Monday, August 20, 07==

After trimming up the basic non-combat moving system (of which I trimmed 200+ lines of code if I remember correctly :( ) I tried to re-implement some things that I really wanted. For example, the way I had it setup normally is the bot would move around a bit then stop, then wait, then move around again then stop, then wait, then move around again. I later realized this wasn't the behavior I wanted, especially when I was working on the squad code where the bot would almost catch up with its leader and then stop and wait for 2-3 seconds. I added a couple of checks so that it would no longer do that but after trimming the code up, the movement code broke (again!). So, I've decided to redo it AGAIN but this time build it from the start specifically for the Squad movement (which seems to be a simpler route to take) rather then implementing a broad movement system that relies on a lot of if statements to work in all situations. It also brings my attention to how I have the functions set up. I have a NonCombat function which calls all of the non-combat associated stuff (mostly movement/rotation atm) and a Combat function which deals with all the combat stuff (and which is also an empty function atm). I hate State so I'm not going to touch those (although if I really sit down to use/figure them out they would probably be much more simpler) but I'm wondering if I should just forget the all seperating Combat and Non-Combat and put it all in one big pot. For now, I think I'll proceed with that in mind so I will have the ability to modify the movement code without destroying functionality.

So, now I will just be focussing on rotating the bot, then moving the bot.

I did some reading up on the Interweb about AI techniques and on one page someone was talking about putting weights on to certain things in the game so the AI would have a "hunger" for it more than others. Epic's AI code does this relatively well I suppose. The reason I'm mentioning it is that I think I may at some point put a value on all of the directions so the bot is more inclined to go in one direction than the other. So, within 90 degrees of wherever he's looking the desire to go in that direction will be greater then to turn around and go back. This kind of idea could be adapted to not just movement but to combat as well. If the bot knows theres someone behind him the weight could shift towards that player so the weight would no longer be in a 90 degree field of view in front of him but a 90 degree behind him.

<div class="hidden-block"><span class="hint">'''''Example Image:'''''</span><div class="hidden">
[[Image:Legacy_Myth_RotationalWeight.jpeg|Legacy_Myth_RotationalWeight.jpeg]] </div></div>

And actually, the more I think about it the more tasty it sounds. This could actually solve the problem of the bot having to know '''exactly''' where the player is. If a player was behind a bot and the bot was aware of this, the bot would spin around and start shooting. Us human players (or at least those of us without aimbots...) have to do vector/angle calculations in our head (really, we do!) so we can aim and fire at our opponent and hopefully if our hand/eye coordination is good (and the computer/server isn't lagging) then we would hit our opponent. However, we SEE the opponent, we KNOW where he is, but we only know a rough estimation. We don't know the exact vector of our opponents. Epics bots, well, I'd hate to being them down, but they're aimbotting smacktards. They pretty much know the -exactly- location of all of their opponents. The only reason why, as Eric has previously stated, they don't get you 100% of the time is because of the AimError on all the weapons which throws their shots off. This proposed rotational weight system could actually help prevent that... or actually, I guess it would create a new kind of 'aim error' but it would be more believable. When the bot turns around to shoot at the opponent, based on the direction of the player and the bot, it would assign a weight system to its rotation, the height 'weight' being the direction the opponent is most likely to end up being at when the bot fires a shot. This wouldn't be exact though (as humans don't have the exact location either, just guestimations) and so the bot will have to 'home-in' on the direction. I'm going to stop there before I get ahead of myself (again...) I just started thinking about having the bot learn from the opponent and save directions that the opponent will most likely come in to his FOV... but lets not go there.

==Sunday, August 19, 07==

I've been doing a lot more Squad AI coding. Just little stuff that will probably make a big difference like allowing the bot to "Hold" a particular location or objective such as a flag. These things will probably be controlled partially by the individual AI but will mostly be controlled by the Squad Leader if the bot is in one. Thats part of the system isn't coded up yet though. Instead, I've decided I really can't put off on re-doing the movement code. The first time through I built it for what I need at that particular time, just a bot that picks a direction and goes there and if they A. Stop moving and aren't just standing still then I force them to either:

1. Go in the opposite direction or

2. Stop moving entirely and wait for the next move decision.

Other cases included hitting "NoGoZone" actor collisions which got them to go the opposite direction also. The system the way it works now is... 'decent', but not 'decent' enough for me to be happy with it. There are too many last minute hacks to get the AI to work with the squad code better so the movement code is really 10 main functions + a few squad hacks here and there. Its really messy and the messiness is starting to show. My bots are getting stuck on walls, the rotational code is messing up now. Just like having to reinstall a windows operating system every once in awhile, an AI totally needs a re-boot.

But that can wait until I get some creative juices flowing again.

==Thursday, August 16, 07==

Due to the fact that I've been so taken with this business of AI coding, I've decided to drop the idea of this third-person mod and stick with just the AI aspect of it. I'm just going to make a GameType that uses my BotAI. It won't be as magnificent as Epics AI code, of course, but thats only because they use the navigation point system so the bot knows exactly where it can go and how to get from point A to point B. My bots basically just feel their way around and if they 'see' anything amazing/wonderful, they mark it down and save it for later. Because of this, I've also decided to drop the restricted movement aspect of it so now the bots are able to go in any direction from 0 to 360 degrees. Of course this requires me to now code up stuff for pitch control/vertical aiming and I'm not sure if that will be extremely hard, or extremely easy.

This new approach would really only be useable in Deathmatch-centered gameplay. Small CTF/DDOM/whatever maps could also be used by the AI but any large scale maps such as CTF-Face3 would be pretty much out of the question unless one joined a squad of bots as the leader and led them to the flag. Although I suppose it could be possible to, instead of using the savedlocation lists in each AI, have a location list used only for Squads. That would probably propose more problems than it would solve though. But right now, the bots can only join squads comprised of themselves.

Its 100x easier to make a bot that knows exactly where he should go, and shoots his opponents with incredible accuracy, and basically just owns, rather than a bot who makes mistakes, actually gets better the longer they play and learns from his opponents. I've been doing with the idea of actually having a navigation list but this list would be generated by the AI itself and saved to an INI most likely. The idea is basically the same as the bots created by various people for Natural-Selection (mod for Half Life). Although, I'm pretty sure the 'waypoint' files used in those systems had to be created manually. The creators of the bots made files for the default maps but any custom maps had to be run without waypoint files/bots wouldn't spawn on custom maps due to no way point files/server admins had to make waypoints themselves. Its that that I want to avoid. IMO, AI's should be able to learn and improve as time goes on. If someone who is new to UT plays a game, they would probably be quite horrible. In fact, people telefrag such players quite often, haha. As time goes on though, and as they rack of game time, their 'skills' eventually improve. They discover shortcuts through maps. They discover ways to get behind the enemy without them knowing. They can distinguish between high risk and low risk opponents. This is what the goal for my AI is. To play, learn, improve. The trick though is to balance giving the bot information that human players don't normally have like the exact position of an enemy player for purposes of aiming. Epic uses a 'faking' system that makes the bot look like they make mistakes, especially with aiming. There is an aimerror variable on each weapon that effects how much they will miss their target. However the higher difficulty you get, the more impossible the bots become and thus, they target, aim, shoot, and kill before you even know whats going on. Unless a human player has an aimbot, and him and his target are extremely skilled, they're both bound to miss a lot. Bots on Godlike, tend not to miss at all. I'm not greatly fond of their aim faking in UT anyways, so I'll probably look for alternative options for faking human characteristics. One thing I don't want at all is Godlike bots.

<div class="hidden-block"><span class="hint">'''''Entry Discussion:'''''</span><div class="hidden">
'''EricBlade:''' This sounds spiffy awesome, and I'm glad I could help. Have you actually built a system where it can move around a level completely independently of pathnodes? The Movement functions have a high reliance on a functioning path network, and I'd love to see a version of that in script rather than in native. One sick thing about the bots, is that once you get to INHUMAN or higher, then you can tell that they are pretty much just shooting everything that has a line of sight to them, and hitting it 90%+ of the time. Bullets and rockets come straight out of their butts. With the existing weapon/aim system, if you remove the AimError stuff, you end up with bots with 100% perfect targetting, at least for hit-scan weapons.

'''MythOpus:''' They can move around an entire level but not very efficiently. It would most likely take them awhile to get from one side of the map to another and they'd most likely get stuck every once in awhile. This will hopefully be improved somewhat as I flesh out how I'm going to get them from point A to B efficiently. I think having a navigation system of sorts would be fairly required but it wouldn't be a static navigation system that you see in UT. It would be more of a dynamic one where bots can add/remove the specific important destinations at will if they see fit when their skill increases. Also, as I've mentioned, it would be a navigation system designed by them so mappers would only be able to have minor control over it. (Then again if I could find a decent way to get them from point A to B and ignore Object C, D and E without using any nagivation system at all then we'd ALL be better off). It would be like finding a short cut after you've been going the long way around to an enemy base.

As with the existing AI, I've always found the rockets and impossible shots very annoying. And as with most bots, theres always away around it. For example, on FaceClassic once you capture the flag, if you hide up in the tower for a few seconds until the enemy bots start coming inside, you can jump off and make it to your base because they still think you're up in the tower. I hope to find dynamic solutions for such things. Imagine, bots who made mistakes (and then corrected those mistakes after playing with you for a bit). Hmmph.

EDIT: Actually, I remember reading somewhere on methods for avoiding 'collision' which could be used for such a thing as avoiding objects C, D, and E but I would have to mess around with those methods heavilly so they wouldn't require navigation systems.

'''EricBlade:''' Considering that I am working with -zombies- of all things, this doesn't sound like a terribly bad behaviour. Any chance you'd be interested in sharing?

'''MythOpus:''' Zombies, huh? Well I am releasing this as open source but I could send you the code that you'd need. Its fairly simple code but I could totally post it up here for you. First though I'll have to work it out again. I've recently chewed it up a bit but I'll put the boken pieces back together to get that Zombie behaviour you're looking for. It IS extended from only Actor though so you may need to work in a few things so it doesn't override certain essential things you might want from your extended classes.</div></div>

==Monday, August 12, 07==

Thanks to EricBlade, my AI (or so it seems) turns the right way 100% of the time now. Now that that works, I need to decide on what I want to work on next. I was toying with the idea of working on squad logic or something for the AI so all of them can stay together relatively well while still doing their own thing. I don't want to get into full-blown combat work yet as I have yet to decide the direction I want to take with it, the majority of that indecision with regards to how the AI will see the player when its supposed to. Because the AI has no access to NavigationPoints at all (Besides the saved locations that it has travelled) I can't just feed it what Nav Point the player is at and fake it seeing the player by checking the distance from the AI. My experiences with Tracing has pretty much thrown that idea out of the window so I'm not quite sure how I'm going to approach that. I suppose I COULD just feed the AI the players location but I agree with a statement made on one of the countless AI sites I've been to. It goes something to this effect... "Artificial Intelligence in games that are in effect omnipresent is something that todays gamers will soon not put up with." So we'll see what happens and we'll see what I start working on next.

==Saturday, August 11, 07==

I thought I'd make an update on my progress, or rather, lack of. I could have probably gotten the majority of the combat system completed and probably would have even fixed the majority of the movement problems if it weren't for not being able to get the AI to turn the right direction. I've made a few leaps in my logic in solving the problem though. Like instead of checking to see if the CurrentYaw was larger/smaller than the DesiredYaw, I am also checking if the DesiredYaw is lesser or greater than the opposite of (CurrentYaw + 180 degrees) to see what direction I should turn but that in itself gave me some errors. So tonight I just gave up and attempted to solve it in a way that I really didn't want to even consider. I attempted to just use IF statements... a lot of if statements. Eight if statements for every quadrant that the CurrentYaw could be in. In these if statements I put together all of the info I put together about what might work to help me. The result? A broken AI that doesn't even rotate to where its supposed to much less rotate in the right direction. It decides to go 90 degrees? It rotates to 225 degrees instead. It stops at 225 degrees and suddenly it thinks its starting from 135 degrees. All I can say is that I am quite dissapointed with it. So just for fun and for anyone who reads this... I will post the most recent Turn Direction Deciding code as well as a helper function I've used in it. If you want to take a knack at deciding where I went wrong go for it, but please oh please post your fixed code here. And if you can condense it, please go ahead and do that too :) I'm sorry if I didn't comment it as much as I should have.

Also, just fyi, the "rotation graph" is inverted horizontally from what you would think. I.E. 90 degrees is on the bottom not the top and 270 degrees is at the top so to get from 0 degrees to 90 degrees you would go clockwise not counter-clockwise.

This also means that Q1 is not in the top-right of a graph but at the bottom right.

<div class="hidden-block"><span class="hint">'''Warning: Large Amount Of Code'''</span><div class="hidden">
<uscript>
//This function decides what would be the best way to turn
//I.E. if you are at 90 degrees and want to move to 300 degrees,
//you don't want to rotate through 180 and 270 degrees just to get there.
//You would want to rotate clockwise.
function AIDecideTurnDirection()
{
//TurnDir = 0 is clockwise.
//TurnDir = 1 is counterclockwise.
//TurnDir = -1 means that the AI won't turn.
//Yes... yes... I know how this could change but that will be done when I get this working >_>

if( !bStandingStill && !bTurnDirSet ) //You don't need to pay attention to this :)
{
//Q1 = 0 to 16384 (0 to 90 degrees)
if( CurrentYaw >= 0 && CurrentYaw <= 16384 )
{
if( DesiredYaw >= 0 && DesiredYaw <= 16384 ) //Same Quadrant As CurrentYaw
{
if( DesiredYaw > CurrentYaw )
TurnDir = 0;
else if( DesiredYaw < CurrentYaw )
TurnDir = 1;
}
else if( DesiredYaw < Add180(CurrentYaw) && DesiredYaw > 16384 )
{
TurnDir = 0;
}
else if( DesiredYaw > Add180(CurrentYaw) && DesiredYaw <= 65536 )
{
TurnDir = 1;
}
else
TurnDir = Rand(1);
}
//Q2 = 16384 to 32768 (90 to 180)
if( CurrentYaw >= 16384 && CurrentYaw <= 32768 )
{
if( DesiredYaw >= 0 && DesiredYaw < 16384 )
{
TurnDir = 1;
}
else if( DesiredYaw >= 16384 && CurrentYaw <= 32768 )
{
if( DesiredYaw > CurrentYaw )
TurnDir = 0;
else if( DesiredYaw < CurrentYaw )
TurnDir = 1;
}
else if( DesiredYaw < Add180(CurrentYaw) && DesiredYaw > 32768 )
{
TurnDir = 0;
}
else if( DesiredYaw > Add180(CurrentYaw) && DesiredYaw <= 65536 )
{
TurnDir = 1;
}
else
TurnDir = Rand(1);
}
//Q3 = 32768 to 49152 (180 to 270)
if( CurrentYaw >= 32768 && CurrentYaw <= 49152 )
{
if( DesiredYaw >= 32768 && DesiredYaw <= 49152 )
{
if( DesiredYaw > CurrentYaw )
TurnDir = 0;
else if( DesiredYaw < CurrentYaw )
TurnDir = 1;
}
else if( DesiredYaw > Add180(CurrentYaw) && DesiredYaw < 32768 )
{
TurnDir = 1;
}
else if( DesiredYaw < Add180(CurrentYaw) && DesiredYaw >= 0 )
{
TurnDir = 0;
}
else if( DesiredYaw > 49152 && DesiredYaw <= 65536 )
{
TurnDir = 0;
}
else
TurnDir = Rand(1);
}
//Q4 = 49152 to 65536 (270 to 360)
if( CurrentYaw >= 49152 && CurrentYaw <= 65536 )
{
if( DesiredYaw >= 49152 && DesiredYaw <= 65536 )
{
if( DesiredYaw > CurrentYaw )
TurnDir = 0;
else if( DesiredYaw < CurrentYaw )
TurnDir = 1;
}
else if( DesiredYaw < Add180(CurrentYaw) && DesiredYaw >= 0 )
{
TurnDir = 0;
}
else if( DesiredYaw > Add180(CurrentYaw) && DesiredYaw < 49152 )
{
TurnDir = 1;
}
else
TurnDir = Rand(1);
}
else if( DesiredYaw == Add180(CurrentYaw) )
TurnDir = Rand(1);

if( DesiredYaw == CurrentYaw)
TurnDir = -1;

bTurnDirSet = True; //We don't need to set the turning direction anymore next tick

}
}

//This takes a UU Degree and adds 180 degrees to it
//And returns a new angle to use
function int Add180(int A)
{
local int NewAngle;
NewAngle = 32768 + A;
if( NewAngle > 65536 ) //We want to be within 0 to 360 degrees
NewAngle = NewAngle - 65536;
if( NewAngle == 65536 )
NewAngle = 0;
else if( NewAngle == 0 )
{
NewAngle = 65536;
}
return NewAngle;
}
</uscript></div></div>

<div class="hidden-block"><span class="hint">'''''Entry Discussion'''''</span><div class="hidden">
'''EricBlade:''' I suppose it might be worth noting that 65536 == -1, so 0 and 65535 should be equivalent. It seems that if you Normalize() your rotators, then you should be able to just figure out which is closer to 0, and that would give you the direction to go .. or am I misunderstanding?

~~ Unreal rotations are modulo 65536, so 65536 == 0 and 65535 == -1. Or, to put it another way: if (RotationValue 1 & 0xffff) == RotationValue2 & 0xffff) then both are the same. 0xffff in decimal is 65535 and (x & 0xffff) is the same as (x % 65536). Note however that Normalize() results in values between -32768 and +32767.

'''EricBlade:''' I think I've stated before that my math skills are a bit rusty and lacking, so I'll need to study that for a bit to figure out how that works. Still, if you Normalize the CurrentRotation and the DesiredRotation, then it seems like you could subtract the DesiredYaw from the CurrentYaw, and if your result is positive, you go one way, and if negative, you go the other?

'''MythOpus:''' I was aware that when talking about bytes it will only go up to 65535 but does that mean I should actually only use the rotations from 0 to 65535 or is it okay if I use 65536? As far as Normalizing CurrentRotation and DesiredRotation and then subtracting DesiredYaw from CurrentYaw, I have code written up for that but theres something wrong with the code that actually rotates the bot around. I wish I would have saved more backups. I will have to fix whatever problem its having first before I can actually test your code though. Thanks for the help so far and by all means, if after studying it for a bit you realize something, do share :)

'''EDIT:''' I just fixed (or so it appears) the rotational code of the AI. It seems I forget to tell it to stop rotating in DirectionX even after it reaches its DesiredYaw. I don't know how I didn't notice that. Anyways, I tested your suggestions (65536 now is 65535, And your sugg. on how to get the proper rotation) and it seems to be the closest thing to perfect compared to all the other bits of code I've tried. However, the code appears to have problems when the DesiredYaw is 45 degrees less than the CurrentYaw and when the small angle between the DesiredYaw and the CurrentYaw are approx. 135 degrees. I.E. If rotating clockwise will have you moving at an angle of 135 degrees, it would decide to move counter clockwise. Any ideas as to why?

<div class="hidden-block"><span class="hint">This is my current function based on your suggestion...</span><div class="hidden">
<uscript>
function AIDecideTurnDirection()
{
local rotator A;

if( !bStandingStill && !bTurnDirSet ) //If the AI has not chosen to stop moving and if the turn dir isn't set...
{

A = Normalize(SetupRotator(CurrentYaw)) - Normalize(SetupRotator(DesiredYaw));

if( A.Yaw > 0 )
TurnDir = 1;
//Note: Currently when A.Yaw is 180 degrees it will just turn clockwise rather than randomize between
//CW and CCW
else
TurnDir = 0;

bTurnDirSet = True; //Hack so it doesn't keep trying to determine turning direction

}
}
</uscript></div></div>

SetupRotator just takes an integer and returns a rotation with a Roll and Pitch of 0 and Yaw of that integer. And on second thought... I might try Normalize( SetupRotator(CurrentYaw) - SetupRotator(DesiredYaw) ) and see where that gets me...

'''Edit 2:''' EricBlade, you get... A delicious batch of...E-Cookies. The AI now rotates in the proper direction! Thank you so very much.

<div class="hidden-block"><span class="hint">The winning code...</span><div class="hidden">
<uscript>
function AIDecideTurnDirection()
{
local rotator A;

A = Normalize( SetupRotator(CurrentYaw) - SetupRotator(DesiredYaw) );

if( A.Yaw > 0 )
TurnDir = 1;
else
TurnDir = 0;
}
</uscript></div></div></div></div>

==Monday, July 23, 07==

I've cleaned/fixed up my AI class. My gameplan now is a few things. Firstly, I need to tweak/fix some more of the AI. Its moving fine but I want it to move more realisticaly. If I were some sort of soldier, I wouldn't walk around all the time and I wouldn't be turning around really fast/a lot. So, I will be tweaking the rotate smooth settings and definitely also need to get it to stop moving around too much. Next on the agenda will be to get some sort of Combat system up and running for the AI. I've already started a bit on what will move me in to the actual combat system. Right now it keeps a list of the spots where its movement ends and will keep track of what directions can't be moved in at that spot. I.E. If the AI is at the top right of the map in a corner, it has to know that it can't move up and can't move any further to the right as it will be blocked by a wall. The AI will then use these locations when in combat to decide good places to go based on where they've seen the player. This system should work fine in small spaces, which will probably be the majority of the mod, but if the AI encounters larger areas it will take quite awhile for it to map out a good understanding of where it could go. I could probably just incorporate scripting such as defense points and what not but I don't want to shy too far away of letting the AI figure things out on its own and doing fairly well at it. After I have a basic combat system up and running, I will probably re-code my player controller to incorporate things like rotate smoothing and other gems. I also need to stop movement when it is against the wall moving at a 45 degree angle to the wall as this will mess up any Combat location things I want to implement. Also, I really, really, really need to get the wall strafing fixed on the player controller. It will still wall strafe off walls and what not, something I don't want the player to do.

==Saturday, July 14, 07==

Just a small update. I finally have the bot rotating properly as it moves. It doesn't -always- turn the way that would take the less time to get to its desired angle, or so it seems but it is good enough for me atm. The next step is to optimize and clean the big mess of code I have been spending my time making. Then I can see if the bot is actually rotating wrong sometimes (which is really hardly noticeable) and then its on to some more movement stuff. Yay.

==Tuesday, July 10, 07==

I was about to start work on the AI's combat system but I decided it would be best if I would continue on the navigation system. I added a few tweaks here and there, mainly seperating the normal moving time and waiting time. This means when the bot is moving around they will have a minimum and maximum time to move. If the bot chooses to sit in one spot, they will have a seperate minimum and maximum duration for waiting. This kind of helps out by stopping the bot a bit. Currently, it keeps moving around really awkwardly. I plan to implement another set of min and max durations for the wait time before picking a different direction to move in. I also implemented a movement smoothing system for the AI (and I'm not sure if I'll implement it for the player) so the bot doesn't make sudden and drastic rotational changes. The problem right now with it though is that A. The bot gets stuck on walls sometimes and B. Because some angles are the same as others ( i.e 360 degrees is the same as 0 degrees ) the bot will only turn one way (his right) when changing rotations. This happens as his velocity is being set so as they're moving they rotate to where they want to look. It moves a bit slow right now but after I fix the few glitches it has, I will tweak the rotation rate etc. Right now, I could just rename the class to Zoolander and no one would be the wiser though. I hate dealing with angles. Now its time to work out a simple and neat progmatical (is that a word?) to have it decide if the direction is closer to his left or right and then start rotating accordingly.

==Saturday, July 07, 07==

Remember that 'gameplan' I was talking about last entry and remember how I didn't finish it? I probably won't. The point of it was more of a little something to keep me focused anyways. The reason for me not finishing it is the same reason I will use for the fact that there has been pretty much 0 work done on the mod: Humidity + Heat = Dalin being very stressed/unable to focus/irritable. This week/next week is full of work too so there is not much I will be able to do even when it does cool down a bit. Its good though. This humidity gives me a reason to clean my room and do other things like play my DS >_>

==Thursday, July 05, 07==

===The Gameplan===

I've been thinking about outlining my plans for the Enemy AI for awhile so her it goes. The AI will be pretty simple. The design goal is to create autonomous (or at least semi-autonomous) enemies that won't rely on NavigationPints or access to player info to be decently effective. The enemy will walk and interact with the world on its own and will require no instruction from the map maker on what to do while still be able to scripted actions if the mapper requires special events to be triggered. I will now seperate and talk about enemy movement and enemy interactions individually.

===Enemy Movement===

In UT2004 and most other games based on the UnrealEngine, enemy AI needs NavigationPoints to move around a given map. Without these NavigationPoints, the enemy will either stay in one spot or move around aimlessly. They will do this until the player comes into their general viscinity at which point they will shoot at the player and try to follow them. This usually ends up with them getting stuck or finding their way back to the spot where they started from. My goal with the movement is to use a similar idea but get rid of the idea of NavigationPoints altogether. The AI will be able to understand, even if only having a vague notion, of what their surrounding environment is.

Since there will only be 8 directions availabe to move in, the AI will walk around their surrounding area. The AI will mark down significant locations such as decent cover positions and the perimeter of the room that they are in. When the player encroaches onto their position and is heard or seen, the enemy will react either by attacking right away or finding cover. The enemy bot will not have any knowledge about the player other then what he hears/sees and if moving towards the players position, the player may have moved away undetected at which point the enemy will appear confused and attempt to locate the player again. Using the perimiter locations as guide, the AI may use this information in an attempt to flank the player.

The AI will still be scriptable but as soon as the script has completed the normal workings of the AI will kick in and the enemy player will move around his environment and watching for the player.

===Enemy Interactions===

Generally speaking, the AI knows everything about the player. Where they are, how much health they have, armor, what weapon they are currently using etc. This gives the AI a one-up on the player. My goal is to eliminate this by forcing the AI to get information for themselves. They will only know what they see/hear and assume. For example, if they see the player come into the room with a slow firing weapon and see him duck behind a crate, they may decide to rush him. However, what they didn't know is that the player switched weapons to a faster weapon and moved into the shadows. Firstly, because the players info isn't available to the AI, they won't be updated on perhaps the best tactics they should use again him or even where he went. Secondly, they might not be able to find him because if the player is in the shadows, the chance that the enemy AI will see him is drastically reduced (he will be a NINJA after all) and so he would be able to attack the AI from behind with a sneak attack or avoiding them altogether and continuing on.

When a bot finds the player, he will alert his squad and then execute whatever tactics he deems neccesary.

'''WIP'''

==Tuesday, July 03, 07==

I decided to move my focus from the player movement system to building what will be the enemy soldiers/aliens/whatever that the player will be up against. I started with the movement system after I got the barebones of the enemy done up, which was basically just a few default varibles to be set. My enemy bot class isn't sub-classed off of Controller because I didn't want a whole bunch of useless variables and functions that I would either not use or have to override. I may decide to do this with the actual player class itself but I haven't decided if it will be worth the trouble.

The movement system of the enemy is pretty simple actually. Much more simpler then that of the players movement which required capturing of inputs and yadda-yadda-yadda. I tried a more complex approach to the AI and got a 'Global' list of navigation points in the GameInfo and made a few functions for the AI to call. When the AI was going to make a move it would call a function in the GameInfo that would create a list of nearby NavigationPoints and decide (randomly) on what point it would tell the AI to move to. I had a few issues with this that related back to when I was trying to implement mouse-click movement of the player, where the player would sometimes go to where you wanted it to but sometimes it would just keep walking past where you clicked. Some pondering about this led me to the conclusion that dealing with it wouldn't be worth my time as even if I '''did''' get it to work, I would still have to deal with the fact that the bot would have to move to far away targets and deal with obstacles and what not. This was not high up on my list of things I would absolutely enjoy doing.

I then came to the conclusion that it would just be a lot simpler and easier to copy the system I'm using for my player's movevments and simulate the inputs. So I set up a tick function that will randomize between 8 integers.

{|

|-
|Integer
|Direction
|-
|0
|Up
|-
|1
|Down
|-
|2
|Left
|-
|3
|Right
|-
|4
|Up + Left
|-
|5
|Up + Right
|-
|6
|Down + Left
|-
|7
|Down + Right
|-
|8
|No Movement
|}

After it decided what direction it would take, I set the rotation to the corresponding direction and the velocity to whatever the default walking speed will be, which is for the purposes of testing, 100. This gets the bot moving (as the walking animation loops) and as it walks several things happen. When it first starts to walk, a counter is set to a random value between a minimum and maximum move time. Then every tick, the counter is decreased until it is 0 at which point a new direction is decided and it starts all over again.

There are some other tid-bits of code involved as well though, for example, a 'small' array that saves the last two directions the bot has moved in. This array is used in an attempt to stop the bot from moving in the same direction over and over again. When a direction is chosen, it is checked against the array to see if the direction should be changed. If the direction is the same as the direction chosen two direction-changes ago, then it should randomize again. This new direction is not saved to the array. We then check to see if the new direction is the same as the direction used prior to the last direction change and if it is, we randomize yet again. If it is still the same as any old direction in the array then we decide that there's nothing we can do and instead we decrease the max time the bot will be moving in that chosen direction. Not the most elegeant way of handling such a thing but it gets the job done for me.

There is much more work to be done though and I think implementing a combat system will be much more easier then my dealings with the player controller.

Note: If you know of a better way to stop a randomized number from being chosen again, please let me know...

==Friday, June 29, 07==

Don't you just LOVE it when the code assigns random values to important variables? I do. After taking a day off from even looking at my code, I loaded up UT to see where I was with it. Apparently, I still haven't fixed the 'wall strafe off the wall and continue wall strafing' issue, something I really need to look at. I found yet another bug in my current iteration of the wall hugging code too. If you wall strafe into the corner then get out of wall strafe mode, then get back in it on the other wall on the other side of the corner, you'll end up with accelerations of -84 in both X and Y axis', and you'll be stuck in wall strafing mode. This convieniently glues you into place. As of right now I have absolutely no idea why this is happening as '84' isn't a value I use anywhere in my code and the acceleration can only be set to 1 of 3 values which are '270' when walking, '500' when running and '120' when wall hugging. I suspect the fact that I haven't 'caught' any cases where the player might try to wall strafe on a diagonal wall might be the cause of the bug, but why it would set my accelerations to -84 is beyond me.

'''Graphik:''' I like it even better when people assume that computers do random things for no reason. ;)

'''MythOpus:''' But Graphik, it DOES have a reason. To annoy me. Remember HAL 2000? My computer is HAL GOBLIN 2000. I stopped it from freezing the player in place but the accleration ends up being 84 all the time still. Now it just won't make a big difference as the player isn't moving anyways.

==Wednesday, June 27, 2007==

Happy Birthday to me.

I decided to take another crack at the wall hugging mode and I finaly got it to work. At least for the most part. Now I have to add some checks to not let the player wall hug if they are going at wall diagonally and I also have to figure out some way to stop the play from wall strafing on walls that don't exist. Currently when a player enters wall hug strafing mode, say, on a pillar of some sort, they will hug the pillar with their back and they will be able to strafe to either side of them and then also move forward (which will take them out of wall strafing mode). This happens wonderfully when a player goes straight into something however if they strafe off the pillar they will keep wall hugging against thin air. To fix this I could do several things, one being force the player to rotate around the pillar or around the wall or whatever but an easier approach would just to add a few checks here and there to determine if the player can move in the opposite direction that they want to rather than being stopped by a wall or other object. I'll think on the subject for a bit.

I also got a laptop for my graduation and birthday so I can get some coding done while at the local cafe. Yippee!

Update: I think I've decided on a solution for my issues. Currently, the wall hugging system requires a player to walk up to a wall and then try and walk into it. At this point, the player will turn around and the player will be locked into wall hug strafing mode. This means that the player will only be able to strafe across the wall or move away from the wall, which will get them out of wall hugging mode. This also means that currently, if they try to go in the direction of the wall again, nothing will happen. This also means however that if the player strafes off a wall, they would strafe into an open hallway and will be hugging against thin air. To solve this issue I've decided that it might be worth to implement a double key wall hugging system sort of like what is implemented in the Metal Gear Solid series. To hug against the wall in those games you must hold down the key that is in the direction of the wall... for example, if the wall was below your player, you would have to hit the down key until you hit the wall and enter wall hugging mode at which point to remain in wall hugging mode you must hold down the down key and to strafe you would use the left/right keys as per normal. I don't forsee this to be a giant issue as all I will probably have to do is change a few lines of code around.

==Monday, June 25, 2007==

I graduate today. Anyways, there hasn't been much working on the mod project as I've been messing around a bit with a Shell for Windows called LiteStep. Its neat. I did however manage to fix, then break, then fix my movement code. I will add that its been about the 10th time where I have had to do this. Whether it is due to my own incompetance or not I will never know. I was messing with the Wall Hugging code and then right out of nowhere, the movement code changes on me and I'm not in any direction I'm supposed to. After this I took out all of the Wall Hugging code and the movement system seemed to work fine for a short while. Then I noticed that some debug code that I have was reporting the wrong direction that the player was moving in. After investigation, it seemed that either I mistakingly changed some Yaw settings or The Goblin decided it would be funny to flip the Y-Axis on me. Oh the life of an amateur UnrealScripter. So I went through all of my calculations and tried to make sense of the mess. The result is this table.

{|

|-
|'''Basic Movement'''
|-
|-
|-
|-
|'''Calculation Used'''
|'''Calculation Value'''
|'''Corresponding Degree'''
|'''Direction'''
|-
|16384*1
|16384
|90
|DOWN
|-
|16384*2
|32768
|180
|LEFT
|-
|16384*3
|49152
|270
|UP
|-
|16384*4
|65536
|360
|RIGHT
|-
|'''Diagonal Movement'''
|-
|-
|-
|-
|'''Calculation Used'''
|'''Calculation Value'''
|'''Corresponding Degree'''
|'''Direction'''
|-
|16384*2 - 16384/2
|24576
|45
|DOWN+RIGHT
|-
|16384*4 + 16384/2
|73728
|135
|DOWN+LEFT
|-
|16384*2 + 16384/2
|40960
|225
|UP+LEFT
|-
|16384*4 - 16384/2
|57344
|315
|UP+RIGHT
|}

So all the angles are negative angles (found clockwise from 0) which makes life very interesting and I can only imagine the newer problems I'll be facing when I decide to start coding the Wall Hugging system again. Right now I'm going to focus on backing up and documenting the code I have in case I screw up.

==Wednesday, June 20, 2007==

I've decided on a general theme for this thing. I've thrown aside magic and monster creatures trying to destroy the world with evil powers in favor of a less common approach. NINJAS! I'm just hoping it won't be over the top lame ninjas, so I'll try extra hard to make it 'cool'.

With this decision made I've had to make a few changes to the code, which started with placeholders. Ninjas don't need magic or magic experience levels or spells... they've got uber skill and knives. I also started to fiddle with the movement system once more even though go it to work the way I wanted it to. I tried adding a wall strafing system. In theory, it would work like this...

The player walks up to a wall. If the player walks into the wall, the players character will lean its back against the wall and you can then move (slowly) against the wall in a similar fashion to the Metal Gear series. This tactic would be useful for getting past heavilly armed guards when there is very little light and could be used as a scare tactic on guards in rooms with pillars every where. Anyways, here is how those changes went.

BOOM!

They didn't work.

I don't quite understand why I'm having so many problems. I'm pretty sure I understand the vector and rotator business so that hopefully isn't the issue. I started to test some things out before I worked heavilly on getting it to work the way I want it to. This required me to strip/trim the existing movement code up a bit so now instead of just setting the rotation of the pawn, I am also setting a custom enum. So when the player is moving forward, the enum will tell you that its moving forward etc. This wasn't the difficult part.

However, then I started to test World Collision things though. I thought that the HitWall event might help me determine if the Pawn is hitting a wall (at which point the wall grab will occur) but this didn't work at all.

Then I attempted to use a FastTrace (albeit with some theoretical variables that I was guessing would work) and that gave extremely odd results. In my test map, I have a room of pillars (just rectangles that reach from top to bottom of the room) and the FastTrace would only show a collision with the left and front of -some- pillars. After fiddling with this to no avail, I tried an actual trace which gave similar results. Also, when the pawn would collide, I had a little piece of code that added 180 degrees to the direction of the pawn (for the huddle against the wall) and this only inverted my movement keys similarly to the problems I was having before with the movement system.

Dalin, is not a happy programmer right now and he has a Calculus Final tomorrow morning. At least the UE Goblin won't be able to ruin that for me.

'''Edit:''' I got the player to 'hug' the wall, minus the animation of course. That will come when most of the code is done. Getting the player to move along the wall has proved much more difficult though. When the player enters the 'wall hug' mode, I've tried different ways to isolate the directions of movement but nothing works so far the way I want it to. I can get the player to run up to a wall and then turn around and 'hug' it, but then in that state I only want the player to be able to move forward which will get him to stop hugging the wall, or be able to move across the surface of the wall while still looking in the forward direction. I.E. The player will strafe across the wall. This has proved hard to implement then I realized. For one, I can't seem to lock the player into the 'wall hug' state properly, and for two, I can't seem to get the player to move across the wall without screwing up my movement axis'. Hopefully doing a semi-rewrite will help me work the kinks out.

----

'''Ambershee:''' You could try creating volumes over walls, and when the player enters them, press up against them, rather than trying to detect walls themselves?

'''MythOpus:''' While a good idea, I don't want the mapper to have to do a lot of extra things to make the mod work as needed. I did thinkof a solution though... while early in the morning of course. I am going to check the location of the pawns location against the location of the pawn a second or so prior. If they are the same then I will work some magic and get the player to look like he's hugging the wall.

'''Ambershee:'''A viable solution, I guess. However what happens if the level designer wants to prevent a player from being able to hug certain walls or surfaces, or a certain wall or surface isn't a brush, but perhaps a mesh or something?

'''MythOpus:'''Well to answer you question about what happens if its not a brush... the system will work the same way. I didn't really explain it well before but here's what I've done. When a player moves somewhere, their rotation changes as well as their acceleration. They accelerate in the direction that they're facing. Because the acceleration of an object can be greater than 0 while the velocity of that object can remain 0, i.e. the object is being stopped by something, I can do the following.

<uscript>
if( ( ( Pawn.Acceleration.X > 1 ) || ( Pawn.Acceleration.Y > 1 ) ||
( Pawn.Acceleration.X < 1 ) || ( Pawn.Acceleration.Y < 1 )) && ( Pawn.Location == OldLocation ) )
{
//Do wall hugging stuff here
}
</uscript>

OldLocation is basically just the previous location of the player when he last tried to move. First we check to see if the player is trying to move in any direction (except for the Z direction because this is a top down rpg and you don't really need to wall hug while falling or jumping) and if thats true then we check to see if the players new location is the same as their previous location, that is to say their velocity is 0. This means for the most part that the player is trying to move but can't, so we can assume that they are trying to move against a wall or pillar, or some other brush or mesh. That won't be the case all of the time of course but you can add/minus stuff to solve any problems.

Note: The check to see if there is any acceleration taking place could probably do with some changing but I didn't know how to check to see if there was any acceleration in any direction otherwise.

To answer you question about the mapper not wanting to allow the player to hug the wall, I'm sure I could use the volume idea as I don't believe there would be any maps where the player wouldn't be able to do this. The only situation where I can see this would be needed is if the mapper had a large vat of boiling lava and didn't want the player getting burnt though. Other than a volume, a trace to a walls surface to get the texture or to a mesh could be used. The information we would get would be checked in some list of 'textures and meshes that you cannot wall hug on' that would be supplied by an in map 'info' actor where the mapper could specify I suppose.

==Tuesday, June 12, 2007==

I haven't really added anything lately. I just implemented a diagonal movement system... nothing major or awe inspiring. I still haven't come up with a concept for this yet though. A techy-ish RPG would probably be the easiest to pull off but I don't want this to become a horrible clone of Alien Swarm. I've prettied up my test map and added an elevator/transit train to test out how my camera settings would react to the player changing z-axis location. I think it should be fine as long as the camera stays within the boundaries of the map. I don't want it to be doing stupid things like not rendering certain objects. Thats pretty much it for now.

==Saturday, June 09, 2007==

I decided I had enough with the mouse problems. My fault. I thought using some 'open source' mousing code would be easilly made to work. Its either a problem with the way I coded it, or as its suggested, not meant to be used with UT2004 as it was written for an engine pre-UT2004 and the measurements and values used may be vastly different. And so, what we have here is a mouse that won't move properly.

Its not all bad news though. I decided to revert back to my old plan of forcing the player to only move in one of four directs, them being up, down, left, right. The reasons I avoided this was because of bugs in the code and I believed to make the bugs go away, I would have to overite the PlayerWalking state, and I despise states.

However, I had to overwrite the player walking state for the mouse code so I thought why not. The overriding is working but not without its problems. The pawn, for some reason or another keeps reverting back its starting rotation (360 or 0 degrees) and I've been trying to track down why unsuccesfully. I will have to burn some code to find out the source of my problems I fear.

'''Update:''' Victory. The problem with the movement code was my fault. Problem with the logic to be precise. I check for any movement on the x or y axis and if there isn't, I don't change the rotation. The problem was that the Acceleration of the player was being decided outside of the if statement 'family' and when it converted the Rotator to the Vector and multiplied it by the players ground speed, it will give a vector with an actual value (because rotator conversions to vectors give a vector with a length of 1 or something to that effect) and then the new acceleration was passed off to some other functions to be used with. Long story short, problem fixed and now its just about getting a hud, new enemy interaction code, a new weapons set ala Zelda, levels, art erm... actually.. I may have a while to go.

==Wednesday, June 06, 2007==

I officially hate vectors. At every example I've seen, getting the distance from one vector to another to done with:

<uscript>
VSize(VectorA - VectorB);
//or
VSize(VectorB - VectorA);
</uscript>

I want to use VSize as for some reason my players location will never equal the location I want it to move to so I have to make it move as close as possible to that location. Two things aren't happening the way I thought they would.
# It seems to be calculating the length of the vector from the origin. From what I remember from Physics, that can lead to complications.
# The 'distance' from Pawn.Location to TargetLocation (where the player wants to go) is never usually less than 256 even if the pawn is right on that spot.

If I don't get an answer to this soon I'm going to move to a less desireable but a million times less stressful solution. I will place an invisible actor where the player wants to go, get the pawn to go in that general direction at whatever speed and when it collides with the invisible actors collion radius, it will stop the pawn. I'm not exactly thrilled about this method though, and it may complicate things if I decide I want to make it a massively multiplayer online roleplaying game, instead of just a roleplaying game.

'''Edit:''' I did a quick implementation of the above idea, to spawn an actor that will stop the pawn when it gets into its collision radius. I extended it from Actor and forgot to set bHidden to true, and I've learnt something quite odd because of it. The reason why VSize appears to be being calculated from the Origin of the Level is because the TargetLocation is being set wrong... This, is going to be fun.

==Saturday, June 02, 2007==

I've recently decided that movement keys are the stupidest things ever... So I'm not going to have them anymore. Instead, the game I'm working on will be almost entirely mouse driven. This for some reason seems to make my job of even getting the basic movement system done that much more complicated. What I have now (that isn't working) is fairly straight forward. Player clicks the mouse somewhere on the map, the players 'avatar' will move to that position and stuff. Whats happening now is that the avatar will move towards the place where the player clicked the mouse, but it will just keep walking. I'm going to have to look at some AI code to figure this out I think.

==Friday, June 01, 2007==

I've recently decided to pick up UnrealScript again after a very long absence of anything programming/scripting related (excluding php). I hoped to refresh my memory on everything UnrealScript in time for the roll out of UT07 (not that I think its going to be worth buying)... and I've already made some forrays into game design that I couldn't do before. The first of these is mouse/cursor support. Thanks to the Mouse Code from UDN I now have a lovely mouse in game, and with a few lovely changes here and there, I have a player finally following the mouse.

This was not without its challenges though. Right now the design idea for this gametype I'm working on is that of an RPG, a top-down perspective one much like Zelda (the originals ie. super nintendo, game boy etc.). I attempted first to lock the rotation of the Players view which was pretty simple. To do this I created a custom Player Controller and overrided the CalcFirstPersonView and CalcBehindView functions. Something like this:

<uscript>
function CalcFirstPersonView( out vector CameraLocation, out rotator CameraRotation )
{
CameraLocation.Z = Pawn.Location.Z + 640; //Get the player view above the player
CameraRotation.Pitch = -16384; //Pitch the camera downward
CameraRotation.Yaw=-16384; //This WAS set to 0 but it was changed... you'll hear about that later
Pawn.bOwnerNoSee = False; //In First Person View, players can't see their own pawn for various reasons but that doesn't
//matter anymore

if(Pawn.Weapon != None) //An ungraceful way of dealing with the first person weapon model... I couldn't get it to 'hide' so,... DESTROY
Pawn.Weapon.Destroy();
}
</uscript>

This worked... for awhile. Until I realized an error on my part. After this I started work on the actual movement of the pawn. It... was stressful. I looked at the UpdateRotation function as it was suggested that it would be a good place to override player input. I used code simlilar to the following to catch the input and change the rotation accordingly.

<uscript>
if( aForward > 0)
NewRotation.Yaw = SomeValue;
else if( aForward < 0)
NewRotation.Yaw = TheOppositeOfSomeValue;
</uscript>

There is more to it than that, for example I also checked for any strafing input, but it didn't work the way I wanted it to. In retrospect, it probably would have worked if I would have fixed my Player View problem (that I'll explain later) but the code I have now is much better I think. I wanted the player movement to be fairly simple. "Up" goes up. "Down" goes down. "Strafe Left" or "Left" goes left. "Strafe Right" or "Right" goes right, just like in most Top-down rpgs. But as I said, it didn't quite work out. At first the forward and reverse directions were okay, but then the left and right directions gave the same results as the forward and reverse, ie. Right went down, Left went up. Changing the angle the player would rotate too only further confused me. I gave up on that for awhile and looked at other options for player movement. I finally found some decent mouse code from UDN, plugged it in and messed with it until it worked as I wanted it to. The source code for the mouse in a 3d space only contained the code for the position of the mouse so I had to mess with it until I could convert the location into a rotation succesfully. Even this gave me troubles though. At first I believed it to be a problem with converting a vector to a rotator. While this may have contributed to the fact that the players rotation never matched up with the mouse, it was not the main problem.

The main problem was that my player view's yaw was wrong. I made some lovely images to clarify.

[[Image:Legacy_Myth_RotationsA.jpeg|Legacy_Myth_RotationsA.jpeg]] Figure 1

[[Image:Legacy_Myth_RotationsB.jpeg|Legacy_Myth_RotationsB.jpeg]] Figure 2

Figure 2 is where it was all wrong. The map I use for testing purpses is a single '''vertical''' room not a horizantal room and my player view was set to make it look like it was actually horiztonal. This played havok with my rotation and caused a lot of things. After I fixed this, everything miracoulously fell into place. Anyways...

Currently I have a player that goes forwards and backwards and rotates in the direction of the mouse. This behaviour may change (I may revert to only having 4 directional movement) but it seems to work for now. All I need to figure is how to add strafing into the movement of the player.

[[Category:Legacy Journal|{{PAGENAME}}]]

User:DalinSeivewright

2008-04-25T03:11:39Z

DalinSeivewright:

== Info ==
*Name:Dalin Seivewright
*Nick: MythOpus
=== Links ===
[[/Old Developer Journal | Archived Developer Journal]] - Mostly (if not all) about my experiences with working on a custom AI derived from the Actor class.

User:DalinSeivewright/Old Developer Journal

2008-04-25T03:10:23Z

DalinSeivewright: User:DalinSeivewright/Developer Journal moved to User:DalinSeivewright/Old Developer Journal

{{classbox| Welcome To MythOpus' Wiki Developer Journal.}}

{{classbox| Journal Entries are sorted from newest to oldest by date.}}

----

=Journal Entries=

==January 26th, 08==

Mmm. Happy Late (x30) New Years. I'm not sure if I mentioned it but I'm back in school again. Since January 7th to be exact. I'm not sure how I feel about it but anyways.

I haven't touched UnrealScript since then. As common for me as that is, I'm kind of dissapointed with myself. Again. In fact, it doesn't look like I'll be working on a major OR minor UnrealScript project for awhile. I did play a decent flash-based 2d game last night though. It was called Smiley Wars, and while the gameplay itself wasn't all that fun, the idea behind it (minus the Smiley's) was a decent one. Games like it have been done before, even multiplayer ones, but this one had a map editor which sparked interest in the first place. Anyways, this game is a Deathmatch game based on 'levels' built on triangles as well as other non-collision objects. Anyways, the map editor wasn't the greatest thing in the world but it got the job done and let you create semi-awesome levels, given the restrictions of the engine itself.

So given that my 'first' language is UnrealScript I tend to prefer writing even pseudo code in UScript form and I've been toying with creating a 2D game like that... except of course with a big more features and a speed boost. Given that I hate working with Flash, I don't know enough of Java, and I don't have my VBasic editor anymore, I'm going to have to work up a concept in UScript form, which will be fun. I don't imagine anything workable coming out of it but we'll see. I may switch to a different language later on.

There's one thing I sort of despise about UnrealScript though. The process for making even the smallest mutator seems to take forever and includes several steps. I think thats one factor associated with me stopping certain projects. You need to make a folder with the name of your package, then within that a folder called classes. Then if you're making a new Gametype you need to find the appropriate GameType to extend, ovveride the appropriate functions (which could take awhile to do if you want certain functionality excluded while keeping certain functionality dependent on the previously excluded functionality. Then comes the default properties which you need to change, at the very least with the Game Name and Description. More so if you're going to be using custom maps, custom pawns, player controllers and AI controllers. Further more in your custom classes, you need to ovveride certain functions and default properties in them.

So, IMO, its just a big huge mess. I haven't touched UT3 yet, fearing that it would be even more of a task. I don't use an IDE either mind you, but thats only because I find most of the IDE's I've tried to be a tad too 'messy'. The only think I code with is UCC and ConText.

At any rate, you might end up seeing my concept ideas on this page from time to time. Anywhere from "I wonder how to do that" to "This is concept code. I'm putting it up here but please don't explicitly steal with like those Flash-game fan boys out there."

That is all.

==Monday, December 24th, 07==

Merry Christmas, first of all if I haven't said it already. Last night was my first normal sleep since I've quit my job. Previously its just been getting up at 12-4 pm, going to sleep at 8 am, and that has really thrown my sleep pattern off and I think I've been getting slightly unhealthy due to it. This week is filled with Christmas supper and what not, so it will be good. I won't be getting very many presents. Not that it truly matters to me (Two christmas' ago, I stated that I want nothing to do with Christmas presents any longer but sure enough I've still be getting a few). I've been mostly playing Guild Wars (which for some reason since Factions came out I have been wanting to buy all of the Campaigns and what not but haven't really 'gotten' into it until a couple of weeks ago. Now I'm actually concerned with how my 'build' fares. Previously, I found all of the talk of 'builds' and such to be annoying and contrary to the intent of the game. I was wrong.

Anyways, I've decided that I need to start from the beginning and go back to the only gametype I've ever released. At that time it was basically just copy and pasted code from Invasion with workarounds to support two teams that battled out for the most points. Unfortunately, I decided that it would be 'cool' to add an option to set the default player health. I had the health value set in my .ini and I didn't give it a second though until after I released it. At this time I had deleted my config and realized that whenever I tried to play a game of Team Invasion, I would not be able to move and shortly after the game would crash. This is when I realized that setting a players health to 0 without killing them is a really bad thing. The default value to set the health at was at 0 and so, if anyone picked up the gametype and didn't see the config option, they would mostly pass it off as a bugged crappy gametype.

I did fix this bug but had problems uploading it to Fileplanet and so, I gave up on it. Shortly after that, I had a hard drive failure and all of it was gone anyways. I have attempted to remake the gametype (and this time from scratch using my own code and so fourth) but every time I did so I stopped working on it because of boredom, as I've already made something like it. I'm making another attempt at it. The note to self was to remember to make a portable warp portal system, similar to the Phase Gates in natural-selection complete with a location menu. So, you would only be able to place once warp portal per zone (per team of course) and when you used said warp portal a selection menu (like the 'v' menu in ut) and it would give you a list of the zones you can warp to that have active warp portals in them. The warp portals can be destroyed. I was thinking these would be cool for larger maps but I'm not sure how useful they would be for a round of team invasion, so I would have to make some sort of strategic signifigance for them as most DM maps aren't very big and using CTF/BR maps doesn't make very much sense as the monsters would spawn on both teams side so there would be no point to kill the players on the opposite team because both teams would still get just as many kills.

That gets me thinking too. In the first iteration of Team Invasion, players could kill monsters and the players on the other team. The point of which was to get big points for killing monsters and getting the other team out of an area with lots of monsters so your own team can get the points for killing them. However, when you died you respawned instantly so you could get back to the spot you were killed at relatively quickly. I guess I'll have to put in a respawn timer like Assault has. I guess that also creates a strategic signifigance for warp portals. Hmph. Food for thought I suppose.

==Tuesday, December 11th, 07==

Oh boy. Its been awhile hasn't it. I can safely say that I have made zero progress on Icarus. In fact, after moving into the new house and getting settled, I figured it would be a great idea to start working on it again. After opening it up in my text editor, and looking through the code, I decided against it. So Icarus is yet another project dedicated to the learning side of things. I did however, start working on something similar to the project I started with. This time I have an actual mouse driven hud thats works though and that I can use to scroll around a given map. What I'm trying to do is use the mouse to place objects on the map. That part works alright, but so far I haven't been able to line up the mouse with the object properly. In fact, what I thought was a flaw in the code, is actually how it would look in real life.

That is, when the mouse is in the center of the screen (and the camera to the level is about 2000 UU's above the object you want to place) then the object appears directly under the mouse. However, when you move the mouse further from the center, the mouse and object no longer line up. I haven't the slightest of ideas on how to 'fix' this 'problem' but it makes placing structures fairly annoying when the object isn't where your mouse is. My problem is that the mouse is drawn on the Canvas and is completely different from a vector. I have the location of the mouse in vector form but that doesn't help me much seeing as the mouse is already drawn on screen and I wouldn't know how to make the neccesary changes to the position of the mouse so that it is always on the object.

Meh. I'll figure it out eventually. Or just stick to a mouse driven 'hero' that'll save the day.

==Saturday, September 29th, 07==

I've hit another snag. This one can neither be avoided or reworked. My laptop I've found out, has a video card that doesn't really support UT2004. Its sort of funny actually and mostly visible from within the editor which is primarily the problem. When you go 'outside' of the map in UED, the walls are supposed to cut away. It seems that when I zoom out, the walls do not cut-away and appear as solid walls that you can't see through. I can work around this, to an extent, but there are other twerks with it that cause the most problems, add to the fact that A. this IS a laptop and B. the monitor on THIS laptop DOES suck for level editing... Then theres the apparent lack of FPS that I seem to get whenever I look at something that would be rendered. Looking into the sky with nothing in your LOS blocking your vision from the skybox gives you roughly 60 fps (which is great, my desktop does less) but as soon as you look at anything else it drops down to 10-20 FPS which isn't fun for A. Online play, B. AI Testing, C. Level Testing or D. Any fun. I haven't really noticed this before unfortunately is because most of my testing has been done on my desktop anyways. This is a problem because the ideas I've had would require 90% of it to be done within levels due to either custom actors that need to be set up or levels in general that require the sort of environment I'm looking for. I really don't think I'm going to be getting any work done, at least not for awhile. I'm living in my Aunties spare bedroom until we find a new house and I still need to find room for my desktop. I really need it setup, at least long enough so I can get some files I need off of it. In the meantime... well... I'll be playing F.E.A.R. (which runs quite well, while UT2004 does not....) and I recently lamed out and bought myself Pokemon Diamond... Don't ask. In fact, I'm reminded of why I quit playing Pokemon. The new Zelda is coming out Tuesday though. This boy is excited.

==Tuesday, September 25th, 07==

I'm moving out of my house on either Wednesday or Thursday and frustration with that fact and various other things has the result of not that much work getting done on this project. My main computer has been decomissioned until I move into this new house (which of course, I don't know what new house I'll be getting...). That puts a serious hamper on my creative juice because most of the things that would inspire me are not on this laptop.

This AI project has frustrated me a lot though, as you may know. I've taken various breaks that have helped a lot, for example, working on a level that for now I am quite satisfied with, at least when I put into perspective my actual skill with regards to level designing. I think the main problem I have is being able to visualize everything wonderfully but I still don't have the technical skills to put it out there. I'm okay with that, my skill has improved a lot since my days of Unreal level designing, which in case you were wondering, were much more fun but a lot less 'beautiful'.

I guess the major issue with this AI project is my need to do things my way. Not saying that doing things 'my' or 'your' way is completely wrong, but if you're looking for compatibility well, then it usually is. My desire to sub-class directly from actor has led to more than one complication. For one, I can't really use any of the movement code inherent in classes like Pawn. Any game related things like death/score/etc look for a Pawn or a Controller, both of which I do not have, to set things up. Not to mention I have to re-invent the wheel even more by mimicking the way the Pawn works so my bots don't do anything that players cannot, like jumping with a z-velocity of 512 rather than 340, or jumping from a really high tower and surviving when normally you would die. Sometimes its easy to do this, sometimes its not so easy.

That being said, it leaves me Three (3) options.

The first, is to keep chugging along like I have been this past couple of months and continue for what most likely will be 6+ months of work, all of which I could have avoided by subclassing the appropriate things and spending a month of overriding and bug fixing.

The second, is to stop work on the AI all together.

The third is to start from scratch and subclass class X,Y,Z as I need them, and use states, like apprently, any sane one would do.

But wait! There is a fourth option! Yes a fourth option. What is this fourth option you ask? Well, it involves having to add/take away X amount of code from the existing code. It involves not hooking into the existing game but rather creating a new Gametype entirely. It will eventually involve faking the Spider physics type. No I won't be making a Spiderman mod.

Actually, I don't know exactly what I'll be doing. I had my heart set on something like Invasion/Alien Swarm, but that can change at any time. I think the AI the way it is now is much more fitting for something like this, aliens/creatures/monsters/ownageness. I had the image of a couple of aliens jumping on and from walls and stuff as the player runs through the hall way and as he's leaving the hall way he notices a gas line on the walls and he dives, turns and shoots the gas line, igniting the baddies. It would resemble a 'sci-fi horror' flick. I also had images of you opening a door and a monster jumping out at you only to disentigrate akin to F.E.A.R. I don't know, its all just musings right now really. I'm going to see if I can fire up my Desktop at my temporary home to get my map and all my files off of it so I will be able to finish that first while I do up some concept stuff for this idea. It really would be a great implementation for the AI in its current state.

==Thursday, September 13, 07==

Goal #1 is completed. I just set the physics to Phys_Walking in the Landed function. I forsee needing that function for other things as well. Instead of moving on to Goal #2, I think I may skip to implementing some jumping, dodging and some random 'logic' stuff.

==Wednesday, September 11, 07==

A few minor, but important things I've discovered. Firstly, there is little to no difference between how Epic gets their pawns moving and how I'm getting my bot moving. I found this out by restricting movement of my bot to only the X axis and sure enough, its Veloctiy and my own Velocity were both 440. So the bot wasn't moving too fast, the animation rate was just too fast and I don't really have anything significant in my test maps to determine how fast its moving. I fired up CTF-FaceClassic and everything looked okay. Secondly, apparently, my bots don't really want to spawn at the exactly location of the PlayerStart. I haven't looked into the cause of this, but something tells me when bots spawn inside the flag room (in Face, PlayerStarts are only outside behind either tower).......

Forget point two. The reason they don't spawn on the playerstarts is beacuse they are being spawned on NavigationPoints so... My bad. On to point number two again though... The design of my previous mod idea has come back to haunt me again. I didn't implement any z-axis movement at all into the bot so its kind of funny to watch them go over the edge in Face, only to hover and move around in circles until they stop. At which point, the fall until they start moving again. The falling down part is probably the native physics taking hold. Anyways, I'll need to work on that part before I do anything else really. I'm also required to work on and finish the weapon firing code. Its basically just a mess of test code that allows the bots to fire through walls and what not. I suppose I'll just make a nice list to keep me on track:
# Implement Z-Axis movement. (I.E. Getting the bot to fall when it needs to fall...)
# Create '''actual''' weapon firing code.
# Get RotationSmoothing to be randomized within a Min and Max value. (To make aiming more realistic-ish)
# Implement some jumping action so the bot can have fun.
# Implement some sort of "ignore player until it makes me angry" random logic. So that the bot doesn't appear to only aim for the players all the time. Current the bot will just aim at you all the time and move toward you and shoot you. This behavior has "...got to go!"
# Implement some dodging.
# Re-implement squad tactics and objectives seeking etc.
# Tweak. Tweak. Then more Tweaking.

I'm beginning to wonder if the ideas I have for making the bot seem more real are going backfire on me. If the aiming setup I have now makes the bot Aim with fairly good accuracy then I'm probably going to have to through in some random directions to face every once in awhile and randomize the aiming restrictions a bit more.

'''Edit:''' And I forget to add the fact that I need to put in some aiming code for the Z-Axis too. Currently the bot can only aim and fire along one plane, that being the X+Y plane.

==Saturday, September 08, 07==

After thinking about interfacing the weapons from UT into my AI, I decided that it would be best to just have it simulate an InstaGib shock rifle, as thats my favorite weapon and gameplay. I've come to a blockade though. I've always assumed that what drove a Pawn to move in direction A was simply something like this: Velocity = vector(Rotation) * GroundSpeed. In reality, it seems much more complex than that. My AI's walking speed was set to something like 100. Realizing the great differences between my (well, my pawns) ability to walk, and its ability to walk, I decided to make the basic movement values the same. So, the AI and the Pawn have walking speeds of 440. Well, my happiness came to a crashing halt. My AI moved 10x faster than I did. After looking into both Controller classes and Pawn classes, and after experimenting with what I saw, I can safely say that I have no idea how Pawns get their movement done. Why couldn't they have just done the previously shown code? I had a great remembrance that the Pawns have Karma Physics working with them. I thought perhaps this created friction so instead of going 100 miles an our, it slowed them down considerably. I was wrong, it seems. I think I'm in for another month of trying to work this out, and then have someone come along and give me a solution. Would that be beneficial to me or not? I don't know.

I even subclassed Pawn instead of Actor. What I got was a lot of hellish rotation and zero movement, regardless of how many functions I overwrote.

==Wednesday, September 05, 07==

Not that much progress at all except for the fact that I've found a decent way to get the AI to use normal weapons without having to make my own. UTRPG has a base weapons class that has a 'Modified Weapon' that it controls. So, if the base weapon were controlling a shock rifle, all of the functions of the shock rifle would be called whenever the appropriate function is called on the base weapon. So function startfire would call startfire on the modified weapon. I suppose I will most likely do it similar to that except I'll have to overide a few things from the controlled weapons for the new aiming system. Hmph.

==Sunday, September 02, 07==

So I'm sitting here at 3:21 AM. I work at 10:30 AM. Before bed, I decide to take one last look at my code to see if I could find anything that I haven't noticed which would be making things difficult for the aiming code. The AI turned perfectly when doing normal rotations but as soon as it was told to aim at me, it rotated stupidly. I knew it would be something small and hard to notice, but I didn't know until now. I assumed the problem lie in my helper functions which added or subtracted a rotation based on some value. While going about it this way I fixed a few problems with the code that I didn't think about. For example, what happens when my rotational code is passed a negative yaw value. When I first encountered this problem, I just thought a nice small absolute function would fix it. I didn't think about the problems that would have though because the -90 degrees is not the same as +90 degrees so and absolute value would make 270 degrees equal to 90 degrees (which means the rotation from the -Yaw value passed will give a mirrored resulting rotation... -90 degrees = 270 degrees but the AI would rotate to 90 degres). [end incoherent rambling]. I added a little bit to fix that, so that problem resolved, but another problem occured when the AI wasn't rotation in the right direction. I knew it couldn't have been any of the rotational code that decided what way the AI should turn because as I said, when the bot isn't aiming, it rotates just fine.

I like to ramble, sorry... the solution for my aiming problem was quite simple. And, I'll even share it with all of you.

<uscript>
bTurnDirSet = False;
//aim code here
</uscript>

I had forgotten that after the AI decides what way it should turn to reach it wanted rotation, I set bTurnDirSet to true so the AI won't keep trying to calculate a new turning direction. Because after every tick the bot tries to aim at the player, bTurnDirSet is always true because unless the bot stops moving, its not set to false so the AI doesn't recalculate its turning direction. Well, now its fixed.

Now the only problem is... interfacing weapons... and moving to a new house soon. Hmph.

==Monday, August 27, 07==

Not much progress has been made since last update, for various reasons.

1. I have no idea what I'll be doing in the future with regards to my life. I had planned on going to school still and just continuing to work at my current job or get a new job working in an area that I'm more suited for. Neither of those plans are looking to good for me.

2. AI Aiming code. I have all of the neccesary components. The bot is supposed to aim at the player. When the bot has rotated to the rotation with which it will use to fire a shot (hopefully hitting the player, for the AI's sake). The code looks great and is implemented into the movement code. The hitch is, it doesn't work.

Well actually, thats not true. The AI DOES rotate and when its within a certain radius it DOES shoot a beam... but it doesn't rotate or shoot in the direction of the player. I have it set up where the player is always this bots target and when it comes within 1024 UU's of its target it starts to 'aim' at the player. When the player comes within 256 uu's the bot starts firing at the player. When the player is within range of either, the AI goes stupid and instead of rotating properly it decides that its going to take 2 hours to rotate to one direction (often passing that direction). When I implemented this and saw this behavior, I was worried that I had broken my rotational code (again!x5) but I observed that when I went out of the aiming range, the bot started to make its own rotational choices and rotated to said rotations normally. So, I didn't break the rotational code... thats great... the Aiming code however evidently needs to be rebuilt.

3. I'm thinking about how I can get the bots to use the existing weapons in game. The problem you ask? The weapons are basically hardcoded to use Epics class tree and methods. Why is this a problem? Why don't I just remake my own weapons? Are you kidding? Remaking all of the existing weapons would be a horrible decision. This is a fairly simple custom bot and with it, it shouldn't need to use custom weapons that do exactly the same thing as the default weapons. I suppose I could just revert back to my plan for making a mod but I don't like that Idea. I need to somehow make an interface between my bot and the current weapons in UT. That also has its own problems. AimError. Eek.

4. Depression. Depression caused by all of the above and probably more. I'm just really bored and have nothing to do. Its a shame... I waste all of my free time.

Anyways, I'll probably rip out the aiming code and do a rewrite of it (again!) and hopefully by the time I move, it will be working.

==Tuesday, August 21, 07==

EricBlade expressed an interest in my AI movement code, so here it is. Keep in mind there are probably several optimization that could be made. Also keep in mind that its basically a rip out of my current AI code which also includes other things. As a result the way I have done some things probably isn't very clear. Some function names could be a bit more, clear, but I've commented on parts that I thought I might need to. This is by no means a final version of the movement code. Things will no doubt be taken out, added or changed. If this breaks you, your computer or anyone else, its not my fault. Also Note, my AI class is directly extended from Actor so I wouldn't have to use a lot of Function overrides and deal with a lot of stupid code. If you use this in any code that does extend from another class, you may need to work it in properly. Have fun. Modify it as you see wish but please give Credit Where It Is Due. When the AI is actually done, I will be releasing it as Open Source anyways so don't do anything stupid :D

'''Update:''' The following code already got a switch up. I'm now in the process of adding rotational code for 3D rather then the 2D stuff leftover from the mod project I was working on which started this whole AI sharade. Also...

Note: The following code only works with the Yaw component of a rotator. Pitch and Roll are excluded from this. Sorry. Wait till release I suppose.

<div class="hidden-block"><span class="hint">Current AI Movement Iteration</span><div class="hidden">
<uscript>
class DS_AIMovement extends Actor;

//Moving System
var bool bMoving; //Is the AI moving?
var bool bStopped; //True when the AI has stopped and is waiting.
var int MovingTime; //The current time left for moving. INTERNAL
var int WaitingTime; //The current time left for waiting. INTERNAL
var vector LastLocation; //The location the AI was at on the last tick.

var bool bWaitTimeSet;
var int MinMovingTime; //Minimum value for the movement time.
var int MaxMovingTime; //Maximum value for the movement time.
var int MinWaitingTime; //Minimum value for the waiting time.
var int MaxWaitingTime; //Maximum value for the waiting time.

var float WalkingSpeed; //The speed used when the AI is walking...
var float CurrentSpeed; //The current movement speed

//Rotation System
var bool bTurnDirSet; //Has the turn direction been chosen?
var int TurnDir; //Direction AI has chosen to turn. 0 - Clockwise 1 - Counter Clockwise
var int RotationSmoothing; //How fast does the AI turn
var int RotationLimit; //How much difference can there be between the AI's Current rotation
//And its Desired rotation
var float DesiredYaw, CurrentYaw; //Desired rotation and current rotation

/*
General Function Section
*/

function PostBeginPlay()
{
//Start with random rotation
CurrentYaw = rand(65536);
SetRotation( SetUpRotator(CurrentYaw) );

MovingTime = Rand(MaxMovingTime - MinMovingTime);
MovingTime = MovingTime + MinMovingTime;

}

function Tick(float DeltaTime)
{
AINonCombat(DeltaTime); //Handles movement and interactivity with the game world when engaged in combat
}

/*
Movement Function Section
*/

/*
Function AINonCombat
Paremeter 1: Type - Float Name - DeltaTime
This function gets the movement all set up and going.
*/
function AINonCombat(float DeltaTime)
{
//While NOT Moving
if( !bMoving )
{
//Note: See notes in the Function Description!!
AIDecideDirection(); //Deciding Direction To Go In

AIStartMove(); //Starting To Move In Decided Direction
}
//While Moving
else
{
AIPreventBlockedMovement(); //If The AI Is Blocked, We Need To Try And Unblock Him
AIDecideTurnDirection(); //Decide Which Way The AI Should Turn To Get To Direction
AIStartRotateProcess(); //Start Rotating To Decided Direction

if( !bStopped )
AIUpdateMovement(); //Updating Velocity And What Not

AIUpdateMovementTimer(); //Updating Movement Timer
}
}

/*
Function AIDecideDirection
Decides what direction it wants to go on
based on its CurrentDirection.
I.E. If RotationLimit is 8192 (45 degrees)
the bot will have a limit to rotate 45 degrees on either side
of its CurrentYaw. So in this case, if the bots
CurrentYaw is 90 degrees, it would only be able to rotate
to anywhere between 45 degrees and 135 degrees.

As an alternative to this system, you can use
AIDecideDirectionOLD. There is no restriction
of where the AI can go with that function.
*/
function AIDecideDirection()
{
local float f; //Decides How Much We Turn
local int NYaw; //The angle to add or subtract

f = fRand() * 2; //Gives us a float between 0 and 2.
NYaw = f * RotationLimit; //Gives us a yaw value between 0 and RotationLimit to add or subtract

if( f < 1 )
//We subtract NYaw from CurrentYaw
DesiredYaw = OperationWithAngle(CurrentYaw, NYaw, False);
else if( f > 1 )
//We add NYaw to CurrentYaw
DesiredYaw = OperationWithAngle(CurrentYaw, NYaw, True);
else
//We do nothing to the CurrentYaw
DesiredYaw = CurrentYaw;
}

/*
Function AIDecideDirectionOLD
Decides what direction it wants to go on.
This new direction could be anywhere between
0 and 65535 (0 to 360).
*/
function AIDecideDirectionOLD()
{
DesiredYaw = Rand(65536);
}

/*
Function AIStartMove()
This function will get that AI moving in its inital rotation and velocity.
It will also start any animations needed.
*/
function AIStartMove()
{
CurrentSpeed = WalkingSpeed;
SetRotation( SetupRotator( CurrentYaw ) );
Velocity = vector(Rotation) * CurrentSpeed;
LoopAnim('WalkF');
bTurnDirSet = False;
bMoving = True;

}

/*
Function AIPreventBlockedMovement
This tells the AI to stop moving if they're being blocked.
TODO: Instead of just stopping the AI, get it to choose another direction to go in.
*/
function AIPreventBlockedMovement()
{
//If the pawn has stopped moving and they haven't chosen to stop
//i.e. they're being blocked by something.
if( !bStopped && (Location == LastLocation) )
{
LoopAnim('Idle_Rest');
bTurnDirSet = False;
bMoving = False;
}
}

/*
Function AIDecideTurnDirection
This function, based on the desired direction, determines which way
the AI should turn to get to its DesiredYaw faster.
For example, if the AI is facing 45 degrees and it wants to face 90 degrees
it would be faster to rotate counter-clockwise then to rotate clockwise.

Note: A great many thanks goes to everyone who tried to help me figure this part out
especially EricBlade from the UWiki who actually figured out the right thing to do.
*/
function AIDecideTurnDirection()
{
local rotator A;

if( !bTurnDirSet )
{
A = Normalize( SetupRotator(CurrentYaw) - SetupRotator(DesiredYaw) );

if( A.Yaw > 0 )
TurnDir = 1; //Counter-Clockwise
else
TurnDir = 0; //Clockwise

bTurnDirSet = True;
}
}

/*
Function AIStartRotateProcess
This function gets the AI rotating the
desired way to the desired direction
*/
function AIStartRotateProcess()
{
//If we've set the turning direction and the AI is not standing still
if( bTurnDirSet && CurrentYaw != DesiredYaw)
{
//If TurnDir is 0 (clockwise)
if( TurnDir == 0 )
{
//If CurrentYaw is greater or equal to 65535 (360)
//Then set it to 0 so we can continue
if( CurrentYaw >= 65535 )
CurrentYaw = 0;

//If CurrentYaw is less than DesiredYaw we need to add to
//CurrentYaw to reach the DesiredYaw.
if( CurrentYaw < DesiredYaw)
//128 is divisible by 8192 (our lowest set yaw value)
//Finding the minimum between CurrentYaw + 128 and DesiredYaw.
//CurrentYaw + 128 will always be chosen until CurrentYaw equals
//or is greater than DesriedYaw.
CurrentYaw = FMin( CurrentYaw + 64*RotationSmoothing, DesiredYaw );
else
//Here we need to find the max because if we get here
//it means that CurrentYaw is greater then Desired yaw but
//We still need to add 128 because we're still going clockwise.
//For example if we're at 315 (45 degrees in real life) and we want to get
//To 45 degrees (315 in real life... remember, the axis' are inverted) then
//we would have to keep adding to CurrentYaw until it gets to 65535 (360 degrees)
//At which point it will be set to 0 and we can continue adding until we reach the DesiredYaw.
CurrentYaw = FMax( CurrentYaw + 64*RotationSmoothing, DesiredYaw );
}
else if( TurnDir == 1 )
{
//If CurrentYaw is less or equal to 0 then
//Set CurrentYaw to 65535 (360)
if( CurrentYaw <= 0 )
CurrentYaw = 65535;

//If CurrentYaw is less than DesiredYaw and CurrentYaw does not equal Zero -FIX ME
if( CurrentYaw < DesiredYaw && CurrentYaw != 0)
//We need to find the minimum value between CurrentYaw - 128 and DesiredYaw.
//We are going counter-clockwise so CurrentYaw - 128 will always be the min value,
//until CurrentYaw is equal or lesser than DesiredYaw.
CurrentYaw = FMin( CurrentYaw - 64*RotationSmoothing, DesiredYaw );
else
//Here we need to finx the Max between the two values because
//We've flipped over 0 and started at 65535
CurrentYaw = FMax( CurrentYaw - 64*RotationSmoothing, DesiredYaw );
}
}
}

/*
Function AIUpdateMovement
Updates rotation and velocity
TODO: Merge with a similar function.
*/
function AIUpdateMovement()
{
SetRotation( SetupRotator( CurrentYaw ) );
Velocity = vector(Rotation) * CurrentSpeed;
}

/*
Function AIUpdateMovement
This function updates the time the AI has left to move.
Also: Decides if there will be a wait time and then updates
that as well.
*/
function AIUpdateMovementTimer()
{
local int iTempHold; //Decides whether we Wait at the end
iTempHold = Rand(5);
//If the AI's moving time is over
if( MovingTime == 0 )
{
bTurnDirSet=False; //We don't know what way we're going to turn so we need to reset that
//Since the moving time is 0 we can... START THE ADDITIONAL WAIT! YAY!

//Setup for the additional wait
if( !bWaitTimeSet )
{
AIStopMovement();
WaitingTime = Rand(MaxWaitingTime - MinWaitingTime);
WaitingTime = WaitingTime + MinWaitingTime;
bWaitTimeSet = True;
}

if( WaitingTime != 0 )
{
WaitingTime--;
}

if( WaitingTime == 0 )
{
//Since the moving time is 0 we can...
//If he's not standing still then reset the moving time for the
//next move. If the AI IS standing still, then MovingTime will
//Use the Waiting Min and Max. Which will be set in the AIStartMove() function.

//Finding the max time it will be.
MovingTime = Rand(MaxMovingTime - MinMovingTime);
//Adding the minimum time to move.
MovingTime = MovingTime + MinMovingTime;

LastLocation = Location;
bWaitTimeSet = False;
bMoving = False; //The AI isn't moving anymore.
bStopped = False;
}

}
else
//If MovingTime isn't 0 then we can keep subracting from it.
//It IS a Moving counter after all.
MovingTime--;
}

/*
Function AIStopMovement
Orders a full stop of the AI.
*/
function AIStopMovement()
{
bStopped = True;
LoopAnim('Idle_Rest');
Velocity = vect(0,0,0);
}

/*
HELPER FUNCTIONS
*/

//Helper Function - Returns a rotator with a Yaw
simulated function rotator SetupRotator(float Yaw)
{
local rotator NewRotation;
NewRotation.Pitch = 0;
NewRotation.Roll = 0;
NewRotation.Yaw = Yaw;
return NewRotation;
}

//Helper Function - Returns a rotator with a Yaw, Roll and Pitch
simulated function rotator SetupSpecialRotator(float Roll, float Pitch, float Yaw)
{
local rotator NewRotation;
NewRotation.Roll = Roll;
NewRotation.Pitch = Pitch;
NewRotation.Yaw = Yaw;
return NewRotation;
}

//Helper Function - Returns opposite angle of A
function int Add180(int A)
{
local int NewAngle;
A = Abs( A );
NewAngle = 32768 + A;
if( NewAngle > 65535 )
NewAngle = NewAngle - 65535;
if( NewAngle == 65535 )
NewAngle = 0;
else if( NewAngle == 0 )
{
NewAngle = 65535;
}
return NewAngle;
}

//Helper Function - Keeps Angles within 0 to 65535...
function int TrimYaw(int A)
{
//Using the Bitwise might work, but I haven't
//Been able to do this properly with it
A = abs( A );
while( A > 65535 )
A = A - 65535;

return A;
}

//Helper Function - Adds or Subtracts Integer B from Integer A
// and keeps it within 0 to 65535..
function int OperationWithAngle(int A, int B, bool bAddition)
{
local int i;
if( bAddition )
{
i = A + B;
i = TrimYaw(i);
return i;
}
i = A - B;

if( i < 0 )
i = 65536 - abs(i);

return i;

}

DefaultProperties
{
// default everything to ThunderCrash.Jakob
Mesh=Mesh'ThunderCrash.JakobM'
Skins(0)=Texture'DemoPlayerSkins.Jakob_Body'
Skins(1)=Texture'DemoPlayerSkins.Jakob_NewHead'
DrawType=DT_Mesh
Style=STY_Normal
bMovable=True
Physics=PHYS_Walking
bCollideWorld=True
bCollideActors=true
bBlockActors = True
MinMovingTime=2000
MaxMovingTime=2250
MinWaitingTime=500
MaxWaitingTime=2000
WalkingSpeed=100
RotationSmoothing = 1
RotationLimit = 8192
}
</uscript></div></div>

==Monday, August 20, 07==

After trimming up the basic non-combat moving system (of which I trimmed 200+ lines of code if I remember correctly :( ) I tried to re-implement some things that I really wanted. For example, the way I had it setup normally is the bot would move around a bit then stop, then wait, then move around again then stop, then wait, then move around again. I later realized this wasn't the behavior I wanted, especially when I was working on the squad code where the bot would almost catch up with its leader and then stop and wait for 2-3 seconds. I added a couple of checks so that it would no longer do that but after trimming the code up, the movement code broke (again!). So, I've decided to redo it AGAIN but this time build it from the start specifically for the Squad movement (which seems to be a simpler route to take) rather then implementing a broad movement system that relies on a lot of if statements to work in all situations. It also brings my attention to how I have the functions set up. I have a NonCombat function which calls all of the non-combat associated stuff (mostly movement/rotation atm) and a Combat function which deals with all the combat stuff (and which is also an empty function atm). I hate State so I'm not going to touch those (although if I really sit down to use/figure them out they would probably be much more simpler) but I'm wondering if I should just forget the all seperating Combat and Non-Combat and put it all in one big pot. For now, I think I'll proceed with that in mind so I will have the ability to modify the movement code without destroying functionality.

So, now I will just be focussing on rotating the bot, then moving the bot.

I did some reading up on the Interweb about AI techniques and on one page someone was talking about putting weights on to certain things in the game so the AI would have a "hunger" for it more than others. Epic's AI code does this relatively well I suppose. The reason I'm mentioning it is that I think I may at some point put a value on all of the directions so the bot is more inclined to go in one direction than the other. So, within 90 degrees of wherever he's looking the desire to go in that direction will be greater then to turn around and go back. This kind of idea could be adapted to not just movement but to combat as well. If the bot knows theres someone behind him the weight could shift towards that player so the weight would no longer be in a 90 degree field of view in front of him but a 90 degree behind him.

<div class="hidden-block"><span class="hint">'''''Example Image:'''''</span><div class="hidden">
[[Image:Legacy_Myth_RotationalWeight.jpeg|]] </div></div>

And actually, the more I think about it the more tasty it sounds. This could actually solve the problem of the bot having to know '''exactly''' where the player is. If a player was behind a bot and the bot was aware of this, the bot would spin around and start shooting. Us human players (or at least those of us without aimbots...) have to do vector/angle calculations in our head (really, we do!) so we can aim and fire at our opponent and hopefully if our hand/eye coordination is good (and the computer/server isn't lagging) then we would hit our opponent. However, we SEE the opponent, we KNOW where he is, but we only know a rough estimation. We don't know the exact vector of our opponents. Epics bots, well, I'd hate to being them down, but they're aimbotting smacktards. They pretty much know the -exactly- location of all of their opponents. The only reason why, as Eric has previously stated, they don't get you 100% of the time is because of the AimError on all the weapons which throws their shots off. This proposed rotational weight system could actually help prevent that... or actually, I guess it would create a new kind of 'aim error' but it would be more believable. When the bot turns around to shoot at the opponent, based on the direction of the player and the bot, it would assign a weight system to its rotation, the height 'weight' being the direction the opponent is most likely to end up being at when the bot fires a shot. This wouldn't be exact though (as humans don't have the exact location either, just guestimations) and so the bot will have to 'home-in' on the direction. I'm going to stop there before I get ahead of myself (again...) I just started thinking about having the bot learn from the opponent and save directions that the opponent will most likely come in to his FOV... but lets not go there.

==Sunday, August 19, 07==

I've been doing a lot more Squad AI coding. Just little stuff that will probably make a big difference like allowing the bot to "Hold" a particular location or objective such as a flag. These things will probably be controlled partially by the individual AI but will mostly be controlled by the Squad Leader if the bot is in one. Thats part of the system isn't coded up yet though. Instead, I've decided I really can't put off on re-doing the movement code. The first time through I built it for what I need at that particular time, just a bot that picks a direction and goes there and if they A. Stop moving and aren't just standing still then I force them to either:

1. Go in the opposite direction or

2. Stop moving entirely and wait for the next move decision.

Other cases included hitting "NoGoZone" actor collisions which got them to go the opposite direction also. The system the way it works now is... 'decent', but not 'decent' enough for me to be happy with it. There are too many last minute hacks to get the AI to work with the squad code better so the movement code is really 10 main functions + a few squad hacks here and there. Its really messy and the messiness is starting to show. My bots are getting stuck on walls, the rotational code is messing up now. Just like having to reinstall a windows operating system every once in awhile, an AI totally needs a re-boot.

But that can wait until I get some creative juices flowing again.

==Thursday, August 16, 07==

Due to the fact that I've been so taken with this business of AI coding, I've decided to drop the idea of this third-person mod and stick with just the AI aspect of it. I'm just going to make a GameType that uses my BotAI. It won't be as magnificent as Epics AI code, of course, but thats only because they use the navigation point system so the bot knows exactly where it can go and how to get from point A to point B. My bots basically just feel their way around and if they 'see' anything amazing/wonderful, they mark it down and save it for later. Because of this, I've also decided to drop the restricted movement aspect of it so now the bots are able to go in any direction from 0 to 360 degrees. Of course this requires me to now code up stuff for pitch control/vertical aiming and I'm not sure if that will be extremely hard, or extremely easy.

This new approach would really only be useable in Deathmatch-centered gameplay. Small CTF/DDOM/whatever maps could also be used by the AI but any large scale maps such as CTF-Face3 would be pretty much out of the question unless one joined a squad of bots as the leader and led them to the flag. Although I suppose it could be possible to, instead of using the savedlocation lists in each AI, have a location list used only for Squads. That would probably propose more problems than it would solve though. But right now, the bots can only join squads comprised of themselves.

Its 100x easier to make a bot that knows exactly where he should go, and shoots his opponents with incredible accuracy, and basically just owns, rather than a bot who makes mistakes, actually gets better the longer they play and learns from his opponents. I've been doing with the idea of actually having a navigation list but this list would be generated by the AI itself and saved to an INI most likely. The idea is basically the same as the bots created by various people for Natural-Selection (mod for Half Life). Although, I'm pretty sure the 'waypoint' files used in those systems had to be created manually. The creators of the bots made files for the default maps but any custom maps had to be run without waypoint files/bots wouldn't spawn on custom maps due to no way point files/server admins had to make waypoints themselves. Its that that I want to avoid. IMO, AI's should be able to learn and improve as time goes on. If someone who is new to UT plays a game, they would probably be quite horrible. In fact, people telefrag such players quite often, haha. As time goes on though, and as they rack of game time, their 'skills' eventually improve. They discover shortcuts through maps. They discover ways to get behind the enemy without them knowing. They can distinguish between high risk and low risk opponents. This is what the goal for my AI is. To play, learn, improve. The trick though is to balance giving the bot information that human players don't normally have like the exact position of an enemy player for purposes of aiming. Epic uses a 'faking' system that makes the bot look like they make mistakes, especially with aiming. There is an aimerror variable on each weapon that effects how much they will miss their target. However the higher difficulty you get, the more impossible the bots become and thus, they target, aim, shoot, and kill before you even know whats going on. Unless a human player has an aimbot, and him and his target are extremely skilled, they're both bound to miss a lot. Bots on Godlike, tend not to miss at all. I'm not greatly fond of their aim faking in UT anyways, so I'll probably look for alternative options for faking human characteristics. One thing I don't want at all is Godlike bots.

<div class="hidden-block"><span class="hint">'''''Entry Discussion:'''''</span><div class="hidden">
'''EricBlade:''' This sounds spiffy awesome, and I'm glad I could help. Have you actually built a system where it can move around a level completely independently of pathnodes? The Movement functions have a high reliance on a functioning path network, and I'd love to see a version of that in script rather than in native. One sick thing about the bots, is that once you get to INHUMAN or higher, then you can tell that they are pretty much just shooting everything that has a line of sight to them, and hitting it 90%+ of the time. Bullets and rockets come straight out of their butts. With the existing weapon/aim system, if you remove the AimError stuff, you end up with bots with 100% perfect targetting, at least for hit-scan weapons.

'''MythOpus:''' They can move around an entire level but not very efficiently. It would most likely take them awhile to get from one side of the map to another and they'd most likely get stuck every once in awhile. This will hopefully be improved somewhat as I flesh out how I'm going to get them from point A to B efficiently. I think having a navigation system of sorts would be fairly required but it wouldn't be a static navigation system that you see in UT. It would be more of a dynamic one where bots can add/remove the specific important destinations at will if they see fit when their skill increases. Also, as I've mentioned, it would be a navigation system designed by them so mappers would only be able to have minor control over it. (Then again if I could find a decent way to get them from point A to B and ignore Object C, D and E without using any nagivation system at all then we'd ALL be better off). It would be like finding a short cut after you've been going the long way around to an enemy base.

As with the existing AI, I've always found the rockets and impossible shots very annoying. And as with most bots, theres always away around it. For example, on FaceClassic once you capture the flag, if you hide up in the tower for a few seconds until the enemy bots start coming inside, you can jump off and make it to your base because they still think you're up in the tower. I hope to find dynamic solutions for such things. Imagine, bots who made mistakes (and then corrected those mistakes after playing with you for a bit). Hmmph.

EDIT: Actually, I remember reading somewhere on methods for avoiding 'collision' which could be used for such a thing as avoiding objects C, D, and E but I would have to mess around with those methods heavilly so they wouldn't require navigation systems.

'''EricBlade:''' Considering that I am working with -zombies- of all things, this doesn't sound like a terribly bad behaviour. Any chance you'd be interested in sharing?

'''MythOpus:''' Zombies, huh? Well I am releasing this as open source but I could send you the code that you'd need. Its fairly simple code but I could totally post it up here for you. First though I'll have to work it out again. I've recently chewed it up a bit but I'll put the boken pieces back together to get that Zombie behaviour you're looking for. It IS extended from only Actor though so you may need to work in a few things so it doesn't override certain essential things you might want from your extended classes.</div></div>

==Monday, August 12, 07==

Thanks to EricBlade, my AI (or so it seems) turns the right way 100% of the time now. Now that that works, I need to decide on what I want to work on next. I was toying with the idea of working on squad logic or something for the AI so all of them can stay together relatively well while still doing their own thing. I don't want to get into full-blown combat work yet as I have yet to decide the direction I want to take with it, the majority of that indecision with regards to how the AI will see the player when its supposed to. Because the AI has no access to NavigationPoints at all (Besides the saved locations that it has travelled) I can't just feed it what Nav Point the player is at and fake it seeing the player by checking the distance from the AI. My experiences with Tracing has pretty much thrown that idea out of the window so I'm not quite sure how I'm going to approach that. I suppose I COULD just feed the AI the players location but I agree with a statement made on one of the countless AI sites I've been to. It goes something to this effect... "Artificial Intelligence in games that are in effect omnipresent is something that todays gamers will soon not put up with." So we'll see what happens and we'll see what I start working on next.

==Saturday, August 11, 07==

I thought I'd make an update on my progress, or rather, lack of. I could have probably gotten the majority of the combat system completed and probably would have even fixed the majority of the movement problems if it weren't for not being able to get the AI to turn the right direction. I've made a few leaps in my logic in solving the problem though. Like instead of checking to see if the CurrentYaw was larger/smaller than the DesiredYaw, I am also checking if the DesiredYaw is lesser or greater than the opposite of (CurrentYaw + 180 degrees) to see what direction I should turn but that in itself gave me some errors. So tonight I just gave up and attempted to solve it in a way that I really didn't want to even consider. I attempted to just use IF statements... a lot of if statements. Eight if statements for every quadrant that the CurrentYaw could be in. In these if statements I put together all of the info I put together about what might work to help me. The result? A broken AI that doesn't even rotate to where its supposed to much less rotate in the right direction. It decides to go 90 degrees? It rotates to 225 degrees instead. It stops at 225 degrees and suddenly it thinks its starting from 135 degrees. All I can say is that I am quite dissapointed with it. So just for fun and for anyone who reads this... I will post the most recent Turn Direction Deciding code as well as a helper function I've used in it. If you want to take a knack at deciding where I went wrong go for it, but please oh please post your fixed code here. And if you can condense it, please go ahead and do that too :) I'm sorry if I didn't comment it as much as I should have.

Also, just fyi, the "rotation graph" is inverted horizontally from what you would think. I.E. 90 degrees is on the bottom not the top and 270 degrees is at the top so to get from 0 degrees to 90 degrees you would go clockwise not counter-clockwise.

This also means that Q1 is not in the top-right of a graph but at the bottom right.

<div class="hidden-block"><span class="hint">'''Warning: Large Amount Of Code'''</span><div class="hidden">
<uscript>
//This function decides what would be the best way to turn
//I.E. if you are at 90 degrees and want to move to 300 degrees,
//you don't want to rotate through 180 and 270 degrees just to get there.
//You would want to rotate clockwise.
function AIDecideTurnDirection()
{
//TurnDir = 0 is clockwise.
//TurnDir = 1 is counterclockwise.
//TurnDir = -1 means that the AI won't turn.
//Yes... yes... I know how this could change but that will be done when I get this working >_>

if( !bStandingStill && !bTurnDirSet ) //You don't need to pay attention to this :)
{
//Q1 = 0 to 16384 (0 to 90 degrees)
if( CurrentYaw >= 0 && CurrentYaw <= 16384 )
{
if( DesiredYaw >= 0 && DesiredYaw <= 16384 ) //Same Quadrant As CurrentYaw
{
if( DesiredYaw > CurrentYaw )
TurnDir = 0;
else if( DesiredYaw < CurrentYaw )
TurnDir = 1;
}
else if( DesiredYaw < Add180(CurrentYaw) && DesiredYaw > 16384 )
{
TurnDir = 0;
}
else if( DesiredYaw > Add180(CurrentYaw) && DesiredYaw <= 65536 )
{
TurnDir = 1;
}
else
TurnDir = Rand(1);
}
//Q2 = 16384 to 32768 (90 to 180)
if( CurrentYaw >= 16384 && CurrentYaw <= 32768 )
{
if( DesiredYaw >= 0 && DesiredYaw < 16384 )
{
TurnDir = 1;
}
else if( DesiredYaw >= 16384 && CurrentYaw <= 32768 )
{
if( DesiredYaw > CurrentYaw )
TurnDir = 0;
else if( DesiredYaw < CurrentYaw )
TurnDir = 1;
}
else if( DesiredYaw < Add180(CurrentYaw) && DesiredYaw > 32768 )
{
TurnDir = 0;
}
else if( DesiredYaw > Add180(CurrentYaw) && DesiredYaw <= 65536 )
{
TurnDir = 1;
}
else
TurnDir = Rand(1);
}
//Q3 = 32768 to 49152 (180 to 270)
if( CurrentYaw >= 32768 && CurrentYaw <= 49152 )
{
if( DesiredYaw >= 32768 && DesiredYaw <= 49152 )
{
if( DesiredYaw > CurrentYaw )
TurnDir = 0;
else if( DesiredYaw < CurrentYaw )
TurnDir = 1;
}
else if( DesiredYaw > Add180(CurrentYaw) && DesiredYaw < 32768 )
{
TurnDir = 1;
}
else if( DesiredYaw < Add180(CurrentYaw) && DesiredYaw >= 0 )
{
TurnDir = 0;
}
else if( DesiredYaw > 49152 && DesiredYaw <= 65536 )
{
TurnDir = 0;
}
else
TurnDir = Rand(1);
}
//Q4 = 49152 to 65536 (270 to 360)
if( CurrentYaw >= 49152 && CurrentYaw <= 65536 )
{
if( DesiredYaw >= 49152 && DesiredYaw <= 65536 )
{
if( DesiredYaw > CurrentYaw )
TurnDir = 0;
else if( DesiredYaw < CurrentYaw )
TurnDir = 1;
}
else if( DesiredYaw < Add180(CurrentYaw) && DesiredYaw >= 0 )
{
TurnDir = 0;
}
else if( DesiredYaw > Add180(CurrentYaw) && DesiredYaw < 49152 )
{
TurnDir = 1;
}
else
TurnDir = Rand(1);
}
else if( DesiredYaw == Add180(CurrentYaw) )
TurnDir = Rand(1);

if( DesiredYaw == CurrentYaw)
TurnDir = -1;

bTurnDirSet = True; //We don't need to set the turning direction anymore next tick

}
}

//This takes a UU Degree and adds 180 degrees to it
//And returns a new angle to use
function int Add180(int A)
{
local int NewAngle;
NewAngle = 32768 + A;
if( NewAngle > 65536 ) //We want to be within 0 to 360 degrees
NewAngle = NewAngle - 65536;
if( NewAngle == 65536 )
NewAngle = 0;
else if( NewAngle == 0 )
{
NewAngle = 65536;
}
return NewAngle;
}
</uscript></div></div>

<div class="hidden-block"><span class="hint">'''''Entry Discussion'''''</span><div class="hidden">
'''EricBlade:''' I suppose it might be worth noting that 65536 == -1, so 0 and 65535 should be equivalent. It seems that if you Normalize() your rotators, then you should be able to just figure out which is closer to 0, and that would give you the direction to go .. or am I misunderstanding?

~~ Unreal rotations are modulo 65536, so 65536 == 0 and 65535 == -1. Or, to put it another way: if (RotationValue 1 & 0xffff) == RotationValue2 & 0xffff) then both are the same. 0xffff in decimal is 65535 and (x & 0xffff) is the same as (x % 65536). Note however that Normalize() results in values between -32768 and +32767.

'''EricBlade:''' I think I've stated before that my math skills are a bit rusty and lacking, so I'll need to study that for a bit to figure out how that works. Still, if you Normalize the CurrentRotation and the DesiredRotation, then it seems like you could subtract the DesiredYaw from the CurrentYaw, and if your result is positive, you go one way, and if negative, you go the other?

'''MythOpus:''' I was aware that when talking about bytes it will only go up to 65535 but does that mean I should actually only use the rotations from 0 to 65535 or is it okay if I use 65536? As far as Normalizing CurrentRotation and DesiredRotation and then subtracting DesiredYaw from CurrentYaw, I have code written up for that but theres something wrong with the code that actually rotates the bot around. I wish I would have saved more backups. I will have to fix whatever problem its having first before I can actually test your code though. Thanks for the help so far and by all means, if after studying it for a bit you realize something, do share :)

'''EDIT:''' I just fixed (or so it appears) the rotational code of the AI. It seems I forget to tell it to stop rotating in DirectionX even after it reaches its DesiredYaw. I don't know how I didn't notice that. Anyways, I tested your suggestions (65536 now is 65535, And your sugg. on how to get the proper rotation) and it seems to be the closest thing to perfect compared to all the other bits of code I've tried. However, the code appears to have problems when the DesiredYaw is 45 degrees less than the CurrentYaw and when the small angle between the DesiredYaw and the CurrentYaw are approx. 135 degrees. I.E. If rotating clockwise will have you moving at an angle of 135 degrees, it would decide to move counter clockwise. Any ideas as to why?

<div class="hidden-block"><span class="hint">This is my current function based on your suggestion...</span><div class="hidden">
<uscript>
function AIDecideTurnDirection()
{
local rotator A;

if( !bStandingStill && !bTurnDirSet ) //If the AI has not chosen to stop moving and if the turn dir isn't set...
{

A = Normalize(SetupRotator(CurrentYaw)) - Normalize(SetupRotator(DesiredYaw));

if( A.Yaw > 0 )
TurnDir = 1;
//Note: Currently when A.Yaw is 180 degrees it will just turn clockwise rather than randomize between
//CW and CCW
else
TurnDir = 0;

bTurnDirSet = True; //Hack so it doesn't keep trying to determine turning direction

}
}
</uscript></div></div>

SetupRotator just takes an integer and returns a rotation with a Roll and Pitch of 0 and Yaw of that integer. And on second thought... I might try Normalize( SetupRotator(CurrentYaw) - SetupRotator(DesiredYaw) ) and see where that gets me...

'''Edit 2:''' EricBlade, you get... A delicious batch of...E-Cookies. The AI now rotates in the proper direction! Thank you so very much.

<div class="hidden-block"><span class="hint">The winning code...</span><div class="hidden">
<uscript>
function AIDecideTurnDirection()
{
local rotator A;

A = Normalize( SetupRotator(CurrentYaw) - SetupRotator(DesiredYaw) );

if( A.Yaw > 0 )
TurnDir = 1;
else
TurnDir = 0;
}
</uscript></div></div></div></div>

==Monday, July 23, 07==

I've cleaned/fixed up my AI class. My gameplan now is a few things. Firstly, I need to tweak/fix some more of the AI. Its moving fine but I want it to move more realisticaly. If I were some sort of soldier, I wouldn't walk around all the time and I wouldn't be turning around really fast/a lot. So, I will be tweaking the rotate smooth settings and definitely also need to get it to stop moving around too much. Next on the agenda will be to get some sort of Combat system up and running for the AI. I've already started a bit on what will move me in to the actual combat system. Right now it keeps a list of the spots where its movement ends and will keep track of what directions can't be moved in at that spot. I.E. If the AI is at the top right of the map in a corner, it has to know that it can't move up and can't move any further to the right as it will be blocked by a wall. The AI will then use these locations when in combat to decide good places to go based on where they've seen the player. This system should work fine in small spaces, which will probably be the majority of the mod, but if the AI encounters larger areas it will take quite awhile for it to map out a good understanding of where it could go. I could probably just incorporate scripting such as defense points and what not but I don't want to shy too far away of letting the AI figure things out on its own and doing fairly well at it. After I have a basic combat system up and running, I will probably re-code my player controller to incorporate things like rotate smoothing and other gems. I also need to stop movement when it is against the wall moving at a 45 degree angle to the wall as this will mess up any Combat location things I want to implement. Also, I really, really, really need to get the wall strafing fixed on the player controller. It will still wall strafe off walls and what not, something I don't want the player to do.

==Saturday, July 14, 07==

Just a small update. I finally have the bot rotating properly as it moves. It doesn't -always- turn the way that would take the less time to get to its desired angle, or so it seems but it is good enough for me atm. The next step is to optimize and clean the big mess of code I have been spending my time making. Then I can see if the bot is actually rotating wrong sometimes (which is really hardly noticeable) and then its on to some more movement stuff. Yay.

==Tuesday, July 10, 07==

I was about to start work on the AI's combat system but I decided it would be best if I would continue on the navigation system. I added a few tweaks here and there, mainly seperating the normal moving time and waiting time. This means when the bot is moving around they will have a minimum and maximum time to move. If the bot chooses to sit in one spot, they will have a seperate minimum and maximum duration for waiting. This kind of helps out by stopping the bot a bit. Currently, it keeps moving around really awkwardly. I plan to implement another set of min and max durations for the wait time before picking a different direction to move in. I also implemented a movement smoothing system for the AI (and I'm not sure if I'll implement it for the player) so the bot doesn't make sudden and drastic rotational changes. The problem right now with it though is that A. The bot gets stuck on walls sometimes and B. Because some angles are the same as others ( i.e 360 degrees is the same as 0 degrees ) the bot will only turn one way (his right) when changing rotations. This happens as his velocity is being set so as they're moving they rotate to where they want to look. It moves a bit slow right now but after I fix the few glitches it has, I will tweak the rotation rate etc. Right now, I could just rename the class to Zoolander and no one would be the wiser though. I hate dealing with angles. Now its time to work out a simple and neat progmatical (is that a word?) to have it decide if the direction is closer to his left or right and then start rotating accordingly.

==Saturday, July 07, 07==

Remember that 'gameplan' I was talking about last entry and remember how I didn't finish it? I probably won't. The point of it was more of a little something to keep me focused anyways. The reason for me not finishing it is the same reason I will use for the fact that there has been pretty much 0 work done on the mod: Humidity + Heat = Dalin being very stressed/unable to focus/irritable. This week/next week is full of work too so there is not much I will be able to do even when it does cool down a bit. Its good though. This humidity gives me a reason to clean my room and do other things like play my DS >_>

==Thursday, July 05, 07==

===The Gameplan===

I've been thinking about outlining my plans for the Enemy AI for awhile so her it goes. The AI will be pretty simple. The design goal is to create autonomous (or at least semi-autonomous) enemies that won't rely on NavigationPints or access to player info to be decently effective. The enemy will walk and interact with the world on its own and will require no instruction from the map maker on what to do while still be able to scripted actions if the mapper requires special events to be triggered. I will now seperate and talk about enemy movement and enemy interactions individually.

===Enemy Movement===

In UT2004 and most other games based on the UnrealEngine, enemy AI needs NavigationPoints to move around a given map. Without these NavigationPoints, the enemy will either stay in one spot or move around aimlessly. They will do this until the player comes into their general viscinity at which point they will shoot at the player and try to follow them. This usually ends up with them getting stuck or finding their way back to the spot where they started from. My goal with the movement is to use a similar idea but get rid of the idea of NavigationPoints altogether. The AI will be able to understand, even if only having a vague notion, of what their surrounding environment is.

Since there will only be 8 directions availabe to move in, the AI will walk around their surrounding area. The AI will mark down significant locations such as decent cover positions and the perimeter of the room that they are in. When the player encroaches onto their position and is heard or seen, the enemy will react either by attacking right away or finding cover. The enemy bot will not have any knowledge about the player other then what he hears/sees and if moving towards the players position, the player may have moved away undetected at which point the enemy will appear confused and attempt to locate the player again. Using the perimiter locations as guide, the AI may use this information in an attempt to flank the player.

The AI will still be scriptable but as soon as the script has completed the normal workings of the AI will kick in and the enemy player will move around his environment and watching for the player.

===Enemy Interactions===

Generally speaking, the AI knows everything about the player. Where they are, how much health they have, armor, what weapon they are currently using etc. This gives the AI a one-up on the player. My goal is to eliminate this by forcing the AI to get information for themselves. They will only know what they see/hear and assume. For example, if they see the player come into the room with a slow firing weapon and see him duck behind a crate, they may decide to rush him. However, what they didn't know is that the player switched weapons to a faster weapon and moved into the shadows. Firstly, because the players info isn't available to the AI, they won't be updated on perhaps the best tactics they should use again him or even where he went. Secondly, they might not be able to find him because if the player is in the shadows, the chance that the enemy AI will see him is drastically reduced (he will be a NINJA after all) and so he would be able to attack the AI from behind with a sneak attack or avoiding them altogether and continuing on.

When a bot finds the player, he will alert his squad and then execute whatever tactics he deems neccesary.

'''WIP'''

==Tuesday, July 03, 07==

I decided to move my focus from the player movement system to building what will be the enemy soldiers/aliens/whatever that the player will be up against. I started with the movement system after I got the barebones of the enemy done up, which was basically just a few default varibles to be set. My enemy bot class isn't sub-classed off of Controller because I didn't want a whole bunch of useless variables and functions that I would either not use or have to override. I may decide to do this with the actual player class itself but I haven't decided if it will be worth the trouble.

The movement system of the enemy is pretty simple actually. Much more simpler then that of the players movement which required capturing of inputs and yadda-yadda-yadda. I tried a more complex approach to the AI and got a 'Global' list of navigation points in the GameInfo and made a few functions for the AI to call. When the AI was going to make a move it would call a function in the GameInfo that would create a list of nearby NavigationPoints and decide (randomly) on what point it would tell the AI to move to. I had a few issues with this that related back to when I was trying to implement mouse-click movement of the player, where the player would sometimes go to where you wanted it to but sometimes it would just keep walking past where you clicked. Some pondering about this led me to the conclusion that dealing with it wouldn't be worth my time as even if I '''did''' get it to work, I would still have to deal with the fact that the bot would have to move to far away targets and deal with obstacles and what not. This was not high up on my list of things I would absolutely enjoy doing.

I then came to the conclusion that it would just be a lot simpler and easier to copy the system I'm using for my player's movevments and simulate the inputs. So I set up a tick function that will randomize between 8 integers.

{|

|-
|Integer
|Direction
|-
|0
|Up
|-
|1
|Down
|-
|2
|Left
|-
|3
|Right
|-
|4
|Up + Left
|-
|5
|Up + Right
|-
|6
|Down + Left
|-
|7
|Down + Right
|-
|8
|No Movement
|}

After it decided what direction it would take, I set the rotation to the corresponding direction and the velocity to whatever the default walking speed will be, which is for the purposes of testing, 100. This gets the bot moving (as the walking animation loops) and as it walks several things happen. When it first starts to walk, a counter is set to a random value between a minimum and maximum move time. Then every tick, the counter is decreased until it is 0 at which point a new direction is decided and it starts all over again.

There are some other tid-bits of code involved as well though, for example, a 'small' array that saves the last two directions the bot has moved in. This array is used in an attempt to stop the bot from moving in the same direction over and over again. When a direction is chosen, it is checked against the array to see if the direction should be changed. If the direction is the same as the direction chosen two direction-changes ago, then it should randomize again. This new direction is not saved to the array. We then check to see if the new direction is the same as the direction used prior to the last direction change and if it is, we randomize yet again. If it is still the same as any old direction in the array then we decide that there's nothing we can do and instead we decrease the max time the bot will be moving in that chosen direction. Not the most elegeant way of handling such a thing but it gets the job done for me.

There is much more work to be done though and I think implementing a combat system will be much more easier then my dealings with the player controller.

Note: If you know of a better way to stop a randomized number from being chosen again, please let me know...

==Friday, June 29, 07==

Don't you just LOVE it when the code assigns random values to important variables? I do. After taking a day off from even looking at my code, I loaded up UT to see where I was with it. Apparently, I still haven't fixed the 'wall strafe off the wall and continue wall strafing' issue, something I really need to look at. I found yet another bug in my current iteration of the wall hugging code too. If you wall strafe into the corner then get out of wall strafe mode, then get back in it on the other wall on the other side of the corner, you'll end up with accelerations of -84 in both X and Y axis', and you'll be stuck in wall strafing mode. This convieniently glues you into place. As of right now I have absolutely no idea why this is happening as '84' isn't a value I use anywhere in my code and the acceleration can only be set to 1 of 3 values which are '270' when walking, '500' when running and '120' when wall hugging. I suspect the fact that I haven't 'caught' any cases where the player might try to wall strafe on a diagonal wall might be the cause of the bug, but why it would set my accelerations to -84 is beyond me.

'''Graphik:''' I like it even better when people assume that computers do random things for no reason. ;)

'''MythOpus:''' But Graphik, it DOES have a reason. To annoy me. Remember HAL 2000? My computer is HAL GOBLIN 2000. I stopped it from freezing the player in place but the accleration ends up being 84 all the time still. Now it just won't make a big difference as the player isn't moving anyways.

==Wednesday, June 27, 2007==

Happy Birthday to me.

I decided to take another crack at the wall hugging mode and I finaly got it to work. At least for the most part. Now I have to add some checks to not let the player wall hug if they are going at wall diagonally and I also have to figure out some way to stop the play from wall strafing on walls that don't exist. Currently when a player enters wall hug strafing mode, say, on a pillar of some sort, they will hug the pillar with their back and they will be able to strafe to either side of them and then also move forward (which will take them out of wall strafing mode). This happens wonderfully when a player goes straight into something however if they strafe off the pillar they will keep wall hugging against thin air. To fix this I could do several things, one being force the player to rotate around the pillar or around the wall or whatever but an easier approach would just to add a few checks here and there to determine if the player can move in the opposite direction that they want to rather than being stopped by a wall or other object. I'll think on the subject for a bit.

I also got a laptop for my graduation and birthday so I can get some coding done while at the local cafe. Yippee!

Update: I think I've decided on a solution for my issues. Currently, the wall hugging system requires a player to walk up to a wall and then try and walk into it. At this point, the player will turn around and the player will be locked into wall hug strafing mode. This means that the player will only be able to strafe across the wall or move away from the wall, which will get them out of wall hugging mode. This also means that currently, if they try to go in the direction of the wall again, nothing will happen. This also means however that if the player strafes off a wall, they would strafe into an open hallway and will be hugging against thin air. To solve this issue I've decided that it might be worth to implement a double key wall hugging system sort of like what is implemented in the Metal Gear Solid series. To hug against the wall in those games you must hold down the key that is in the direction of the wall... for example, if the wall was below your player, you would have to hit the down key until you hit the wall and enter wall hugging mode at which point to remain in wall hugging mode you must hold down the down key and to strafe you would use the left/right keys as per normal. I don't forsee this to be a giant issue as all I will probably have to do is change a few lines of code around.

==Monday, June 25, 2007==

I graduate today. Anyways, there hasn't been much working on the mod project as I've been messing around a bit with a Shell for Windows called LiteStep. Its neat. I did however manage to fix, then break, then fix my movement code. I will add that its been about the 10th time where I have had to do this. Whether it is due to my own incompetance or not I will never know. I was messing with the Wall Hugging code and then right out of nowhere, the movement code changes on me and I'm not in any direction I'm supposed to. After this I took out all of the Wall Hugging code and the movement system seemed to work fine for a short while. Then I noticed that some debug code that I have was reporting the wrong direction that the player was moving in. After investigation, it seemed that either I mistakingly changed some Yaw settings or The Goblin decided it would be funny to flip the Y-Axis on me. Oh the life of an amateur UnrealScripter. So I went through all of my calculations and tried to make sense of the mess. The result is this table.

{|

|-
|'''Basic Movement'''
|-
|-
|-
|-
|'''Calculation Used'''
|'''Calculation Value'''
|'''Corresponding Degree'''
|'''Direction'''
|-
|16384*1
|16384
|90
|DOWN
|-
|16384*2
|32768
|180
|LEFT
|-
|16384*3
|49152
|270
|UP
|-
|16384*4
|65536
|360
|RIGHT
|-
|'''Diagonal Movement'''
|-
|-
|-
|-
|'''Calculation Used'''
|'''Calculation Value'''
|'''Corresponding Degree'''
|'''Direction'''
|-
|16384*2 - 16384/2
|24576
|45
|DOWN+RIGHT
|-
|16384*4 + 16384/2
|73728
|135
|DOWN+LEFT
|-
|16384*2 + 16384/2
|40960
|225
|UP+LEFT
|-
|16384*4 - 16384/2
|57344
|315
|UP+RIGHT
|}

So all the angles are negative angles (found clockwise from 0) which makes life very interesting and I can only imagine the newer problems I'll be facing when I decide to start coding the Wall Hugging system again. Right now I'm going to focus on backing up and documenting the code I have in case I screw up.

==Wednesday, June 20, 2007==

I've decided on a general theme for this thing. I've thrown aside magic and monster creatures trying to destroy the world with evil powers in favor of a less common approach. NINJAS! I'm just hoping it won't be over the top lame ninjas, so I'll try extra hard to make it 'cool'.

With this decision made I've had to make a few changes to the code, which started with placeholders. Ninjas don't need magic or magic experience levels or spells... they've got uber skill and knives. I also started to fiddle with the movement system once more even though go it to work the way I wanted it to. I tried adding a wall strafing system. In theory, it would work like this...

The player walks up to a wall. If the player walks into the wall, the players character will lean its back against the wall and you can then move (slowly) against the wall in a similar fashion to the Metal Gear series. This tactic would be useful for getting past heavilly armed guards when there is very little light and could be used as a scare tactic on guards in rooms with pillars every where. Anyways, here is how those changes went.

BOOM!

They didn't work.

I don't quite understand why I'm having so many problems. I'm pretty sure I understand the vector and rotator business so that hopefully isn't the issue. I started to test some things out before I worked heavilly on getting it to work the way I want it to. This required me to strip/trim the existing movement code up a bit so now instead of just setting the rotation of the pawn, I am also setting a custom enum. So when the player is moving forward, the enum will tell you that its moving forward etc. This wasn't the difficult part.

However, then I started to test World Collision things though. I thought that the HitWall event might help me determine if the Pawn is hitting a wall (at which point the wall grab will occur) but this didn't work at all.

Then I attempted to use a FastTrace (albeit with some theoretical variables that I was guessing would work) and that gave extremely odd results. In my test map, I have a room of pillars (just rectangles that reach from top to bottom of the room) and the FastTrace would only show a collision with the left and front of -some- pillars. After fiddling with this to no avail, I tried an actual trace which gave similar results. Also, when the pawn would collide, I had a little piece of code that added 180 degrees to the direction of the pawn (for the huddle against the wall) and this only inverted my movement keys similarly to the problems I was having before with the movement system.

Dalin, is not a happy programmer right now and he has a Calculus Final tomorrow morning. At least the UE Goblin won't be able to ruin that for me.

'''Edit:''' I got the player to 'hug' the wall, minus the animation of course. That will come when most of the code is done. Getting the player to move along the wall has proved much more difficult though. When the player enters the 'wall hug' mode, I've tried different ways to isolate the directions of movement but nothing works so far the way I want it to. I can get the player to run up to a wall and then turn around and 'hug' it, but then in that state I only want the player to be able to move forward which will get him to stop hugging the wall, or be able to move across the surface of the wall while still looking in the forward direction. I.E. The player will strafe across the wall. This has proved hard to implement then I realized. For one, I can't seem to lock the player into the 'wall hug' state properly, and for two, I can't seem to get the player to move across the wall without screwing up my movement axis'. Hopefully doing a semi-rewrite will help me work the kinks out.

----

'''Ambershee:''' You could try creating volumes over walls, and when the player enters them, press up against them, rather than trying to detect walls themselves?

'''MythOpus:''' While a good idea, I don't want the mapper to have to do a lot of extra things to make the mod work as needed. I did thinkof a solution though... while early in the morning of course. I am going to check the location of the pawns location against the location of the pawn a second or so prior. If they are the same then I will work some magic and get the player to look like he's hugging the wall.

'''Ambershee:'''A viable solution, I guess. However what happens if the level designer wants to prevent a player from being able to hug certain walls or surfaces, or a certain wall or surface isn't a brush, but perhaps a mesh or something?

'''MythOpus:'''Well to answer you question about what happens if its not a brush... the system will work the same way. I didn't really explain it well before but here's what I've done. When a player moves somewhere, their rotation changes as well as their acceleration. They accelerate in the direction that they're facing. Because the acceleration of an object can be greater than 0 while the velocity of that object can remain 0, i.e. the object is being stopped by something, I can do the following.

<uscript>
if( ( ( Pawn.Acceleration.X > 1 ) || ( Pawn.Acceleration.Y > 1 ) ||
( Pawn.Acceleration.X < 1 ) || ( Pawn.Acceleration.Y < 1 )) && ( Pawn.Location == OldLocation ) )
{
//Do wall hugging stuff here
}
</uscript>

OldLocation is basically just the previous location of the player when he last tried to move. First we check to see if the player is trying to move in any direction (except for the Z direction because this is a top down rpg and you don't really need to wall hug while falling or jumping) and if thats true then we check to see if the players new location is the same as their previous location, that is to say their velocity is 0. This means for the most part that the player is trying to move but can't, so we can assume that they are trying to move against a wall or pillar, or some other brush or mesh. That won't be the case all of the time of course but you can add/minus stuff to solve any problems.

Note: The check to see if there is any acceleration taking place could probably do with some changing but I didn't know how to check to see if there was any acceleration in any direction otherwise.

To answer you question about the mapper not wanting to allow the player to hug the wall, I'm sure I could use the volume idea as I don't believe there would be any maps where the player wouldn't be able to do this. The only situation where I can see this would be needed is if the mapper had a large vat of boiling lava and didn't want the player getting burnt though. Other than a volume, a trace to a walls surface to get the texture or to a mesh could be used. The information we would get would be checked in some list of 'textures and meshes that you cannot wall hug on' that would be supplied by an in map 'info' actor where the mapper could specify I suppose.

==Tuesday, June 12, 2007==

I haven't really added anything lately. I just implemented a diagonal movement system... nothing major or awe inspiring. I still haven't come up with a concept for this yet though. A techy-ish RPG would probably be the easiest to pull off but I don't want this to become a horrible clone of Alien Swarm. I've prettied up my test map and added an elevator/transit train to test out how my camera settings would react to the player changing z-axis location. I think it should be fine as long as the camera stays within the boundaries of the map. I don't want it to be doing stupid things like not rendering certain objects. Thats pretty much it for now.

==Saturday, June 09, 2007==

I decided I had enough with the mouse problems. My fault. I thought using some 'open source' mousing code would be easilly made to work. Its either a problem with the way I coded it, or as its suggested, not meant to be used with UT2004 as it was written for an engine pre-UT2004 and the measurements and values used may be vastly different. And so, what we have here is a mouse that won't move properly.

Its not all bad news though. I decided to revert back to my old plan of forcing the player to only move in one of four directs, them being up, down, left, right. The reasons I avoided this was because of bugs in the code and I believed to make the bugs go away, I would have to overite the PlayerWalking state, and I despise states.

However, I had to overwrite the player walking state for the mouse code so I thought why not. The overriding is working but not without its problems. The pawn, for some reason or another keeps reverting back its starting rotation (360 or 0 degrees) and I've been trying to track down why unsuccesfully. I will have to burn some code to find out the source of my problems I fear.

'''Update:''' Victory. The problem with the movement code was my fault. Problem with the logic to be precise. I check for any movement on the x or y axis and if there isn't, I don't change the rotation. The problem was that the Acceleration of the player was being decided outside of the if statement 'family' and when it converted the Rotator to the Vector and multiplied it by the players ground speed, it will give a vector with an actual value (because rotator conversions to vectors give a vector with a length of 1 or something to that effect) and then the new acceleration was passed off to some other functions to be used with. Long story short, problem fixed and now its just about getting a hud, new enemy interaction code, a new weapons set ala Zelda, levels, art erm... actually.. I may have a while to go.

==Wednesday, June 06, 2007==

I officially hate vectors. At every example I've seen, getting the distance from one vector to another to done with:

<uscript>
VSize(VectorA - VectorB);
//or
VSize(VectorB - VectorA);
</uscript>

I want to use VSize as for some reason my players location will never equal the location I want it to move to so I have to make it move as close as possible to that location. Two things aren't happening the way I thought they would.
# It seems to be calculating the length of the vector from the origin. From what I remember from Physics, that can lead to complications.
# The 'distance' from Pawn.Location to TargetLocation (where the player wants to go) is never usually less than 256 even if the pawn is right on that spot.

If I don't get an answer to this soon I'm going to move to a less desireable but a million times less stressful solution. I will place an invisible actor where the player wants to go, get the pawn to go in that general direction at whatever speed and when it collides with the invisible actors collion radius, it will stop the pawn. I'm not exactly thrilled about this method though, and it may complicate things if I decide I want to make it a massively multiplayer online roleplaying game, instead of just a roleplaying game.

'''Edit:''' I did a quick implementation of the above idea, to spawn an actor that will stop the pawn when it gets into its collision radius. I extended it from Actor and forgot to set bHidden to true, and I've learnt something quite odd because of it. The reason why VSize appears to be being calculated from the Origin of the Level is because the TargetLocation is being set wrong... This, is going to be fun.

==Saturday, June 02, 2007==

I've recently decided that movement keys are the stupidest things ever... So I'm not going to have them anymore. Instead, the game I'm working on will be almost entirely mouse driven. This for some reason seems to make my job of even getting the basic movement system done that much more complicated. What I have now (that isn't working) is fairly straight forward. Player clicks the mouse somewhere on the map, the players 'avatar' will move to that position and stuff. Whats happening now is that the avatar will move towards the place where the player clicked the mouse, but it will just keep walking. I'm going to have to look at some AI code to figure this out I think.

==Friday, June 01, 2007==

I've recently decided to pick up UnrealScript again after a very long absence of anything programming/scripting related (excluding php). I hoped to refresh my memory on everything UnrealScript in time for the roll out of UT07 (not that I think its going to be worth buying)... and I've already made some forrays into game design that I couldn't do before. The first of these is mouse/cursor support. Thanks to the Mouse Code from UDN I now have a lovely mouse in game, and with a few lovely changes here and there, I have a player finally following the mouse.

This was not without its challenges though. Right now the design idea for this gametype I'm working on is that of an RPG, a top-down perspective one much like Zelda (the originals ie. super nintendo, game boy etc.). I attempted first to lock the rotation of the Players view which was pretty simple. To do this I created a custom Player Controller and overrided the CalcFirstPersonView and CalcBehindView functions. Something like this:

<uscript>
function CalcFirstPersonView( out vector CameraLocation, out rotator CameraRotation )
{
CameraLocation.Z = Pawn.Location.Z + 640; //Get the player view above the player
CameraRotation.Pitch = -16384; //Pitch the camera downward
CameraRotation.Yaw=-16384; //This WAS set to 0 but it was changed... you'll hear about that later
Pawn.bOwnerNoSee = False; //In First Person View, players can't see their own pawn for various reasons but that doesn't
//matter anymore

if(Pawn.Weapon != None) //An ungraceful way of dealing with the first person weapon model... I couldn't get it to 'hide' so,... DESTROY
Pawn.Weapon.Destroy();
}
</uscript>

This worked... for awhile. Until I realized an error on my part. After this I started work on the actual movement of the pawn. It... was stressful. I looked at the UpdateRotation function as it was suggested that it would be a good place to override player input. I used code simlilar to the following to catch the input and change the rotation accordingly.

<uscript>
if( aForward > 0)
NewRotation.Yaw = SomeValue;
else if( aForward < 0)
NewRotation.Yaw = TheOppositeOfSomeValue;
</uscript>

There is more to it than that, for example I also checked for any strafing input, but it didn't work the way I wanted it to. In retrospect, it probably would have worked if I would have fixed my Player View problem (that I'll explain later) but the code I have now is much better I think. I wanted the player movement to be fairly simple. "Up" goes up. "Down" goes down. "Strafe Left" or "Left" goes left. "Strafe Right" or "Right" goes right, just like in most Top-down rpgs. But as I said, it didn't quite work out. At first the forward and reverse directions were okay, but then the left and right directions gave the same results as the forward and reverse, ie. Right went down, Left went up. Changing the angle the player would rotate too only further confused me. I gave up on that for awhile and looked at other options for player movement. I finally found some decent mouse code from UDN, plugged it in and messed with it until it worked as I wanted it to. The source code for the mouse in a 3d space only contained the code for the position of the mouse so I had to mess with it until I could convert the location into a rotation succesfully. Even this gave me troubles though. At first I believed it to be a problem with converting a vector to a rotator. While this may have contributed to the fact that the players rotation never matched up with the mouse, it was not the main problem.

The main problem was that my player view's yaw was wrong. I made some lovely images to clarify.

[[Image:Legacy_Myth_RotationsA.jpeg|]] Figure 1

[[Image:Legacy_Myth_RotationsB.jpeg|]] Figure 2

Figure 2 is where it was all wrong. The map I use for testing purpses is a single '''vertical''' room not a horizantal room and my player view was set to make it look like it was actually horiztonal. This played havok with my rotation and caused a lot of things. After I fixed this, everything miracoulously fell into place. Anyways...

Currently I have a player that goes forwards and backwards and rotates in the direction of the mouse. This behaviour may change (I may revert to only having 4 directional movement) but it seems to work for now. All I need to figure is how to add strafing into the movement of the player.

[[Category:Legacy Journal|{{PAGENAME}}]]

User:DalinSeivewright/Developer Journal

2008-04-25T03:10:23Z

DalinSeivewright: User:DalinSeivewright/Developer Journal moved to User:DalinSeivewright/Old Developer Journal

#REDIRECT [[User:DalinSeivewright/Old Developer Journal]]

Unreal Wiki talk:Task list

2008-04-22T17:02:10Z

DalinSeivewright: response - Can admins contribute to this at all? :)

UE1 talk:RJumpPad

2008-04-22T15:05:36Z

DalinSeivewright: For Raven

Raven: When I saw you add this page to the (now deleted) Open Source page on the new Wiki (not the Legacy one) I assumed you wanted it on the new license. Since it was decided to not have a Open Source page and just move custom classes to a namespace for the engine it was made for (in this case the UE1 namespace) and give it a Custom Class category. Anyways, I just noticed you added a link to this page to an old Legacy page ( [[Legacy:Third-Party_Components]] ). Even though new content should probably go under the new License (Creative Commons: BY NC SA), I'm not sure now if you wanted this custom class to be under the old license (in which case you can move it from here to [[Legacy:RJumpPad]], unless an admin disagrees :) ) or if you wanted it under the new license (in which case you can just keep it here).

In any case you can read up on on changes at [[Unreal_Wiki:MediaWiki_conversion | the conversion page]] if you haven't done so already :) -[[User:DalinSeivewright|DalinSeivewright]] 15:05, 22 April 2008 (UTC)

Talk:Main Page

2008-04-22T05:49:24Z

DalinSeivewright: sig

Unreal Wiki talk:Community portal

2008-04-22T05:42:43Z

DalinSeivewright: response

Wow! No main discussion page yet! Hope you all don't mind this comment. Never been on a wiki before. --EscapingTheSilence

:Most of the discussion is happening on [[Talk:Main Page]]. -[[User:Wormbo|Wormbo]] 11:34, 11 April 2008 (UTC)

I'm not sure I see the vision for this page. Is it to be a portal to other closely-related sites? Perhaps links to modding community sites? Or will it just be a depository for recent {{SITENAME}} news and links for new recruits? -[[User:DalinSeivewright|DalinSeivewright]] 03:59, 18 April 2008 (UTC)

It seems to be the new [[Legacy:UnrealWiki_To_Do]]++. —''[[User:Graphik|Graphik]] 04:20, 18 April 2008 (UTC)''

Well if thats the case then [[Unreal_Wiki:Task_list]] is wasted :P The Community Portal should be centered around budding developers (i.e. links to developer journals, etc.) and general wiki user (i.e. featured user, etc.). -[[User:DalinSeivewright|DalinSeivewright]] 05:42, 22 April 2008 (UTC)

Unreal Wiki talk:Task list

2008-04-22T05:40:10Z

DalinSeivewright: 2 cents

User talk:16mentaltempest

2008-04-22T05:27:25Z

DalinSeivewright: Hello 16mentaltempest!

Hello and welcome to the Wiki. I've moved your page to [[User:16mentaltempest]] as thats where User pages are supposed to go. You can go directly to your page by clicking on your name when you login and on your name on the Recent Changes. This is to seperate Unreal content from Wiki content :) You can also sign your name like so: <nowiki>-~~~~</nowiki>. Have fun :) -[[User:DalinSeivewright|DalinSeivewright]] 05:27, 22 April 2008 (UTC)

User:16mentaltempest

2008-04-22T05:23:49Z

DalinSeivewright: 16mentaltempest moved to User:16mentaltempest: User pages belong in the User namespace.

==The Modest Mapper: Tips I've Learned Over Time==

===DM-GTarena===
I originally submitted this map under my old name Ju.L.Mo. It is a stadium with two levels of seating, a stage, and a small backstage area. Most of the texturing was done with UTtech1 and ShaneChurch.
The Good:
*Bots worked well
*Remembered to add music and screenshot
The Bad:
*BSP was a disaster
*Texturing was inconsistent
*All white lighting
*Layout forced bots to the bottom level
*Did not beta test before release
What I Learned:
*Use semi-solids to avoid BSP problems
*Avoid all white lighting
*Use more consistent textures
*Be sure to beta test

===DM-Volant (Beta)===
So far this map is on the backburner with extra special plans to bring it back from the dead. It is a small research facility hovering over a crater. Texturing done using UTtech1/PlyrShip.
The Good:
*Textures were consistent
*Added little details like computers and crates
The Bad:
*Bots were not well pathed
*Plain incandescent lighting
*Layout was terrible
*No skybox completed
What I Learned:
*How to create terrain
*Avoid plain incandescent lighting
*Take into account layout when pathing
*Use a layout that flows and connects everything to everywhere

===DM-GTarena][ (Beta)===
After the Nalicity crash I got this map back in order to fix a few things on it. Most of what I've done so far has been technical stuff and slight retexturing.
The Good:
*BSP is much cleaner
*Texturing is slightly more consistent
*No more custom 'ad' textures
The Bad:
*Haven't changed the lighting
*Still need to fix texturing
What I Learned:
*When and where to use semi-solids and how to fix errors involving them

===CTF-Vieux (In Progress)===
Currently, I am working on my first CTF map. It is a basic design with texturing from Crypt2. The map is an ancient fortress with the two bases inside and you run around the fort to get to the other flag. Outside there are trenches and extra hallways for offense and defense.

===AS-RadarRider (Concept)===
This one is a long way off, but I can still dream.