Difference between revisions of "Category talk:OpCodes"
(New categories) |
(→Radically new and detailed format) |
||
(4 intermediate revisions by 2 users not shown) | |||
Line 22: | Line 22: | ||
So, is my format of describing the opcodes good? | So, is my format of describing the opcodes good? | ||
+ | |||
+ | :Format is good, but IMO would be better to describe opcodes completely right away its page is created, without leaving it for future. [[User:Seemann|Seemann]] 10:16, 29 Sep 2007 (CDT) | ||
== New categories == | == New categories == | ||
− | I think we really need to start categorize opcodes into additional categories, like "Conditional", "Math", "San Andreas only", "Interface", etc. | + | I think we really need to start categorize opcodes into additional categories, like "Conditional", "Math", "San Andreas only", "Interface", etc. [[User:Seemann|Seemann]] 10:13, 29 Sep 2007 (CDT) |
+ | |||
+ | == Radically new and detailed format == | ||
+ | |||
+ | Check [[01C3|this]] out. What do you think? Instead of the parameter ## format that becomes inconsistent across de/compilers and the file itself, I use data types to label the parameters. Syntaxes from four programs that I know, including raw file information, are shown. Icons with HR tags replace the text for supported games. The Stories are separated with brief information. The example shows how the opcode can be used in a practical way, and was made so that one code can support all three games. If this format looks good to you, I will attempt to make a new opcode template.--[[User:Spaceeinstein|Spaceeinstein]] 18:35, 13 August 2011 (UTC) | ||
+ | :Hi. I like new format (especially the game icons instead of the titles) except two things. First, I think that describing syntax for all the known tools is waste of time as I guess only a few people are still not using SB nowadays. You will fall in trouble describing opcodes that were discovered recently and are not present in those tools config files. So, not so many people will be interested in that information. Same goes to the raw hex data. Second, I doubt that adding the Stories opcodes is correct. If I'd coded for the LCS and wanted to find out what opcode 01C8 means, I would open the [[01C8]] page. Since there's no working Stories compiler available, this information will only confuse most of the readers. <span style="font-family:Courier New">'''{{#if:Seemann|[[User:Seemann|Seemann]]}}<sup>[[Special:Contributions/Seemann|?]][[User_talk:Seemann|!]]</sup>'''</span> 14:37, 15 August 2011 (UTC) | ||
+ | |||
+ | ::Ok, I will place other compiler's syntax and Stories opcodes in a separate list for reference.--[[User:Spaceeinstein|Spaceeinstein]] 06:46, 16 August 2011 (UTC) |
Latest revision as of 06:46, 16 August 2011
It is very important to include all the info about opcodes we have to the wiki. But should there be more unified way of naming the separate pages? I suggest to use the titles like title=opcode_0000, title=opcode_0001 and so forth.
- You're right, Seemann, that's the only way to go, as there isn't (and will never be) an official naming convention for opcodes.
- Additionally, we have to establish a blueprint for the general design of an Opcode Description page - which syntaxes to include, explanation of parameters and so on.
- But personally, I fear that this domain will never be used for modding reference. Most opcodes can still be found at xx-db.webtools4you.net, a 'proper' database, so I don't see the urgent need for listing them here. Not every kind of content is appropriate for being wikied.
- We would rather need a more general approach to mission coding, especially with the beginners in mind, describing 'best practices' (use of waits/player_defined checks), delivering a proper introduction and tutorial - possibly with extensive examples, so that it gets as easy as possible to produce some working code. SteaVor 06:45, 15 Apr 2007 (CDT)
- oh, sorry, forgot about signing. as for the db vs. wiki, that db never gives to us such possibilities that wiki can (cross-reference links, examples, categories and such). So we MUST expand this part of wiki as it possible. And I see that the db is full of spam last days, hope the wiki can avoid that. Seemann 10:58, 15 Apr 2007 (CDT)
- OK, so let's try it here. The first task would be defining the actual layout for such a description page. When I look at the few opcodes that have already been added, I see no conformity at all - not even speaking of contributions that denote 'Hammer83' as 'Hammer32'!
- Let's begin it! SteaVor 13:44, 15 Apr 2007 (CDT)
- As I see, a page should have 3 parts:
- 1. brief info about opcode (short description=like INI alias; number of parameters; games supported it)
- 2. explanation of the parameters. Full info about, including cross-references with other opcodes/categories
- 3. Example of using, tricks, known features (undocumented possibilities)
- Not sure about TOC at the top of a page, maybe it's not necessary. Seemann 06:11, 17 Apr 2007 (CDT)
- As I see, a page should have 3 parts:
- I fully agree with everything you said, that's how it should look and work. We should begin with improving the existing pages and then adding the most important opcodes first, instead of simply going down the list.
- Did you already look at (and compared) the opcode pages that already exist? Why are there 'unused' ones included of all things? What a waste of space...SteaVor 10:35, 17 Apr 2007 (CDT)
For the sake of completion, I will just dump all the known opcodes all at once and edit them later.
So, is my format of describing the opcodes good?
- Format is good, but IMO would be better to describe opcodes completely right away its page is created, without leaving it for future. Seemann 10:16, 29 Sep 2007 (CDT)
New categories
I think we really need to start categorize opcodes into additional categories, like "Conditional", "Math", "San Andreas only", "Interface", etc. Seemann 10:13, 29 Sep 2007 (CDT)
Radically new and detailed format
Check this out. What do you think? Instead of the parameter ## format that becomes inconsistent across de/compilers and the file itself, I use data types to label the parameters. Syntaxes from four programs that I know, including raw file information, are shown. Icons with HR tags replace the text for supported games. The Stories are separated with brief information. The example shows how the opcode can be used in a practical way, and was made so that one code can support all three games. If this format looks good to you, I will attempt to make a new opcode template.--Spaceeinstein 18:35, 13 August 2011 (UTC)
- Hi. I like new format (especially the game icons instead of the titles) except two things. First, I think that describing syntax for all the known tools is waste of time as I guess only a few people are still not using SB nowadays. You will fall in trouble describing opcodes that were discovered recently and are not present in those tools config files. So, not so many people will be interested in that information. Same goes to the raw hex data. Second, I doubt that adding the Stories opcodes is correct. If I'd coded for the LCS and wanted to find out what opcode 01C8 means, I would open the 01C8 page. Since there's no working Stories compiler available, this information will only confuse most of the readers. Seemann?! 14:37, 15 August 2011 (UTC)
- Ok, I will place other compiler's syntax and Stories opcodes in a separate list for reference.--Spaceeinstein 06:46, 16 August 2011 (UTC)