Always snap to grid

Talk:Main Page

From Unreal Wiki, The Unreal Engine Documentation Site
Jump to: navigation, search

UnrealScript API[edit]

Wouldnt it be more useful to have some sort of contents for API documentation?

So I pulled this list from the references talk page as its not really relevant 'directly' to the unreal script language but its classes. Not having a contents page makes it tricky to traverse, I understand that the class pages are much better documented then in the past but as an eg, spawn(), if I didnt know to look for it I wouldnt find it. So Im proposing a contents, the above is no where near a suggestion its just a stub of pages that could go into the API documentation contents, cool. --00zX 03:40, 22 April 2010 (UTC)

General layout[edit]

I've tried to come up with a compact initial layout and topic list. Suggestions for improvements are welcome. 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 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. -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. -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? -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. -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. -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 -OlympusMons 23:29, 21 April 2008 (UTC)

Double post looolz, anyways to expand on class tree's I had a play over here: Sandbox but I think it'll need its own template or something and Im not well versed on this new wiki stuff just yet. This category list shows the pages though under the categories they fall but I couldnt get the parent class showing as a category which is why I thought it'd need a template. -OlympusMons 16:51, 27 April 2008 (UTC)

New wiki software / Organization[edit]

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. – 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.
-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. – Haarg 17:17, 5 April 2008 (UTC)
wow. Unreal Wiki had a makeover... This will be confusing for a while...--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. – 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. -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. – 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? -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. - 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. -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. -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.
On a semi-related note: Do we want to document defaultproperties, possibly including subobjects, on the class pages? -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. -DalinSeivewright 05:49, 22 April 2008 (UTC)
Please have a look at UE3:UIObject (UT3), I've updated it with the basic default value and subobject output of the wikifier. I still need to add special parsing for struct values to link any enums or subobjects used there. Suggestions about the output are welcome. -Wormbo 09:23, 27 April 2008 (UTC)

Mod ideas[edit]

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? -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? -DalinSeivewright 06:26, 25 April 2008 (UTC)
Better leave mod ideas to ppl's own wiki pages -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. – 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. -DalinSeivewright 16:09, 25 April 2008 (UTC)
Isn't the entire point of posting mod ideas that others should pick them up? -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? :) -DalinSeivewright 18:23, 25 April 2008 (UTC)

I've removed the Modding ideas link from the main page. That page should really be dissolved and the individual ideas should be posted on the contributing users' personal pages. Once that is done, Category:Mod ideas could be linked from Modding overview, but not from the main page. —Wormbo 20:16, 21 November 2008 (UTC)

Category link description[edit]

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:

A
[[Apple]] - This page describes what an apple is.
O
[[Orange]] - This page describes what an orange is.

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. -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. -Wormbo 16:54, 25 April 2008 (UTC)

Some form of this could be done using a DPL report:

But that would be built as a specific list, and not part of the general category page. – Haarg 17:49, 25 April 2008 (UTC)

3rd Party / open source scripts[edit]

Where do they go? (O Kelvin)

As a page with the the appropriate namespace and page name. UE1:RJumpPad for example. With a class infobox, it will be added to the appropriate categories. – Haarg 23:30, 27 April 2008 (UTC)
Ops... I made edits to the Legacy:Third party components page -_- User:0 Kelvin
How about adding a "Projects" starting point ? It would be ideal for grouping all the third-party code detailed on the wiki and make it easily accessible. I mean, think of those people who are getting started with unrealscript. Documentation sometimes isn't enough and snippets of code could serve as examples. At the moment, it's a pain finding anything and one usually has to type random phrases in Google to get access to anything interesting. --Azura 01:14, 6 April 2009 (UTC)

Battering Ram[edit]

Well, this is the First Time i ever wrote anything on here, and it's actually more of a question, or plea for help, than anything else. I am NOT a programmer, but am very familiar with most of the language having mapped since Doom, not Doom3, Doom... but I have come across an interesting problem I can't solve.

I am trying to make a vehicle, with a Battering Ram. I have the Vehicle, what I need is the Battering Ram. My idea was to take the static mesh from the Shock Tank Shield, resized and converted to my vehicle static mesh package, and use it as a Projectile, that travels a very short distance, at a high rate of speed and Batters whatever it hits and stops projectiles like a shield. It works, my problem is though, when it is aimed low, it disappears. It is still there as far as hammering actors, and other momentum/damage effects, but there is no visibility.

I've tried making it in over 5 different ways now, projectile, emitter, pawn, actor, u name it, i tried it, all worked but with same disappearing act. I suspect it has something to do with collision size, but i've tried it with or without, and nothing seems to work. I used the Shield Shader as the Texture, Have collision of texture true, tried using other meshes, even a square, Even recoded the whole gun to use the shield from the Shock Tank, with redone emitter effect just to see and even the emitter effect said "GoodBye!".

I'd put up the code I last used but it's basically the Projectile Code, altered to launch the static mesh and right now has every collision property i could find, in defaults, set to true.

So if someone finds the idea interesting, or you're just bored, ANY help is Good Help...


Honestly, for "interactive" modding help you should really ask in a forum. The Unreal Wiki is more of a reference site. If you are looking for or want to help writing tutorials, then this is the place for you. —Wormbo 18:19, 9 May 2009 (UTC)

IRC[edit]

Shouldn't we have some mention about the Unreal IRC channels such as #UnrealScript and #UnrealWiki? on the main page, perhaps there is and i didn't see it but in that case it should be moved so people will see it. --Eliot 22:39, 17 July 2010 (UTC)

"Modding" section[edit]

What exactly is the point of that section? I mean, modding is the act of modifying a game. You can do so by creating custom levels ("Mapping"), custom models ("Modeling") or changing the rules on any scale from small additions to a totally new game ("Programming"). And apart from that obvious ambiguity - check out [[Modding overview], it's a joke. —Wormbo

yeah I dont know what the purpose of it was (I went ahead and removed it, revert if needed anyways), maybe it was some sort of section to combine all three sections but this can be done in a much better fashion if required in tutorials. Using a basic proceedure approach to tutorials though each of the smaller tutorials would reside in their apropriate sections, mapping, modeling or programming, cool --00zX 08:57, 2 August 2010 (UTC)

IRC?[edit]

What the heck does IRC stand for, and why don't any of the links do anything when I click them? Yours truly UnrealMuskrat 00:06, 20 June 2014 (UTC)

IRC means Internet Relay Chat. It's an old, yet still quite popular chat protocol for which you need a special client. Thunderbird can do it natively, there's ChatZilla for Firefox, there are many dedicated programs like mIRC and multi-protocol chat programs like Miranda, Pidgin or Trillian. —Wormbo 14:36, 20 June 2014 (UTC)

Cool, chats are awesome, pretty cool how you've got 4 to choose from. I'll have to learn how to get these things working for me, I love to chat. Yours truly UnrealMuskrat 21:50, 21 June 2014 (UTC)

File Reference List[edit]

What I need for publishing map packages is a list of stock and non stock files for UT with respect to the UT versions and addons/bonus packs. Usually I use birrabrothers.com and a clean fresh UT installation to find that out. Wouldn't be the Wiki a matching place for such a collection? --SeriousBarbie (talk) 18:58, 29 December 2015 (EST)

IIRC we do have such lists for particular types of packages. A complete file list is probably more admin-related than modding-related and thus should maybe belong in the Unreal Admin Wiki. —Wormbo 19:34, 29 December 2015 (EST)
Retrieved from "https://wiki.beyondunreal.com/Talk:Main_Page?oldid=46280"