|
|
| (65 intermediate revisions by 29 users not shown) |
| Line 1: |
Line 1: |
| __NOTOC__[[Category:RockPatch]]{{RockPatch}} | | __NOTOC__[[Category:RockPatch]]{{RockPatch}} |
| | {{Wishlist/TOC}} |
|
| |
|
| {| align="center" width="98%" class="table_parted"
| | =Attention!= |
| !colspan="2"|Introduction | | This page is '''obsolete'''. Feature requests are now managed through the [http://bugs.renegadeprojects.com/set_project.php?ref=view_all_set.php%3Ftype=3%26source_query_id=10&project_id=6 Issue Tracker]. |
| |-
| |
| |width="50%"|<div align="center">'''What this List is'''</div>You're looking at the community-editable wishlist for [[User:pd|pd]]'s [[RockPatch:Main|RockPatch]].
| |
|
| |
|
| If you would like to see a specific feature added to RockPatch, add it at an appropriate place on this list. ''Do not contact pd in any other way.'' It just doesn't work that way. If the entire community started IM sessions and bugged pd about features the moment he signed on, he'd soon quit making the patch at all.<br>
| | ===How to request a Feature=== |
| As such, all wishes ''not'' made through the wishlist will be ignored. (And, most likely, pd will remember you in a way not helping other wishes you have.)
| | Go to [http://bugs.renegadeprojects.com/set_project.php?ref=view_all_set.php%3Ftype=3%26source_query_id=10&project_id=6 bugs.renegadeprojects.com]. Click on <code>Login</code>. If you have an account, log into it. If you want to be informed about your request's outcome, plan to request several features, or want to report bugs later, click <code>Signup for a new account</code> and register; if not, click <code>Login Anonymously</code>. Once you are logged in, either normally or anonymously, click on <code>Report Issue</code>. If you didn't do so already, the system will ask you to select a project. Choose <code>RockPatch2</code> and click <code>Select Project</code>. Now set:<br> |
| | *'''Category:''' Feature Request |
| | *'''Reproducibility:''' N/A |
| | *'''Severity:''' feature |
| | *'''Product Version:''' ''empty'' |
| | *'''Summary:''' A one-sentence description of your request - this is what will appear in the issue list, so if you want pd to actually read it, summaries like "ADD THIS PLEASE!!!1!!" are not a good idea. |
| | *'''Description:''' A detailed description of your request - don't write novels, but the more details you have, the easier pd can assess the wish. |
| | *'''Additional Information:''' What the title says - possibly a summarized list of the suggested ini flags or something like that. Anything you have in your head about your wish that doesn't quite fit into the request as such. |
| | *'''Upload file:''' This is mainly used for bug reports, but if you did something like a photoshop mockup of your request, you could attach it here. |
| | *'''View Status:''' Public |
| | *'''Report Stay:''' If you wish to return to the report form to add more requests or bug reports, check this. |
|
| |
|
| Also note [[RockPatch:Votelist|the Votelist]].
| | Afterwards, click <code>Submit Report</code>. Congratulations, you just requested a feature. |
| |width="50%"|<div align="center">'''What this List is not'''</div>
| |
| *This is '''not''' a list of ''demands''.
| |
| *These are '''not''' features that ''are'' already implemented.
| |
| *This list does '''not''' guarantee the feature ''will'' be implemented.
| |
| |-
| |
| |width="100%" colspan="2"|<div align="center">'''Where to put your Wish'''</div>
| |
| *There are several topical lists, choose the one that fits best.
| |
| *Newer wishes are added to the bottom.
| |
| *The list was spread over several pages for a reason. ''Keep it that way.'' (Look at the history to see why.)
| |
|
| |
|
| '''Example:''' You wish to request a warhead-feature. That would, of course, be a Totally New Feature. However, ''Weapons related'' fits even better for something about warheads. Weapons related is on Page 5. So your wish belongs to Page 5, Weapons related, at the bottom of the list. | | ===The Reason for this Change=== |
| |}
| | On first glance, this new procedure may look a lot more complicated than the previous one, but check out what you get in return: |
| | *'''Status reports''' - each request is a single item in the database with its own status information like priority, eta, status, etc., etc.; you won't just know whether pd generally works on your request, but you can see in detail how long he things it'll take, how far he is, and in which version it will be available. |
| | *'''Comments''' - in the past, there were often opinions or improvement suggestions on wishes by other users. For reasons of order, commenting directly on the page was prohibited; on the tracker, this is not the case. As each issue has its own page, everyone can leave a note at the bottom specifically for that wish, giving his opinion or suggesting improvements for it. |
| | *'''[http://bugs.renegadeprojects.com/set_project.php?ref=roadmap_page.php&project_id=6 Roadmap] & [http://bugs.renegadeprojects.com/set_project.php?ref=changelog_page.php&project_id=6 Changelog]''' - with both feature requests and bugs tracked by the same system, said system can directly and immediately calculate how close to completion the currently worked on version is. No need to wait for updated wiki pages or forum posts - just check the percentage on the roadmap! |
|
| |
|
| {{quote|pd|I just want to underline that this is not a demand list but only a collection of ideas because I'm the only person who has the possibility to change anything at the moment... teaching others how to do this would be a solution but it would mean much learning to them (I think).<br>
| | And that's just what ''you'' get out of it. For pd, it means a lot less management effort, and an easy way to quickly assess, prioritize and plan feature additions. When he dismisses a wish, it's marked as dismissed. When he chooses a wish, it's automatically on the roadmap. A cleaner environment for both sides, and less time spent updating ModEnc for pd. |
| I will choose the easiest for me and the most useful for the community things first.<br>
| |
| So don't be angry if you're wish doesn't get "fulfilled".}}
| |
| | |
| =General Bugfixes/Corrections=
| |
| {{Wishlist/TOC}}
| |
| *Fixing the 74-unit-bug, aka whiteboy bug
| |
| *Fixing of the "Tank Bunker only allows ground locomotor units" issue (it should allow hover locomotor too).
| |
| *Fixing of the "TIBMINExx is hardcoded to spawn xx entry from {{tt|[Tiberiums]}}" issue, preferably changing xx to an INI-controlled value
| |
| *Fixing of the "{{tt|AttachedParticleSystem=}} nullifies {{tt|Burst=}}" issue
| |
| *Fix various hardcoded YR bugs. See {{tt|[http://marshall.cannis.net/ump/index.htm#bugs]}} for list.
| |
| *Fix Carryall Logic for Hind.
| |
| *Fix Debris Logic/Improve it
| |
| *Rumor has it that {{tt|NonVehicle=yes}} does not actually block Vehicle Hijackers, it just gives a no entry cursor and still lets them hijack...this needs fixing.
| |
| *{{tt|NonVehicle=yes}} also needs to prevent the Tote action (carryall logic) from grabbing the unit too.
| |
| *{{tt|UseOwnName=true}} cannot be used on a VehicleType (only InfantryTypes). Any vehicle placed inside an IFV will cause the IFV to have a name of "Rocket IFV" (or Repair/Machine Gun if IFV mode 1/2/3).
| |
| *Any way to optimize cloaking code or speed it up
| |
| *Fix VehicleThief and Thief logic (currently, you need both to get hijackers to work but the infantry can then enter refineries to no effect)
| |
| *Fix the PrismSupportModifier bug (if a {{tt|[General]}} section is declared on a map and a value is not defined there, the value is set to infinite or something)
| |
| *The use of {{tt|HoverPad=yes}} causes an Internal Error if the AI uses a Nuke or Weather Storm. This is a pain because the {{tt|HoverPad=yes}} can be used to make hover units land on service depots and, better yet, allows an airpad to come with a free aircraft - but we can't use it because of the damned IE!<br>Not so much of a problem, see discussion.
| |
| *having 2 PKT files makes some maps get listed ingame twice. can you fix this?
| |
| *Fix adding new {{tt|[BuildingTypes]}} breaking single player campains. See this link for a better description: [http://www.cannis.net/tutorials/ra2yr_nobreak_yrmissions1/]}}
| |
| *Fix code so you can build all units of a BuildLimit >1 in a row<br>(right now, if you have {{tt|BuildLimit=10}}, for example, you can only build 9, something else, and then the last one)
| |
| *The 'sell unit' function can be resurrected using a super weapon. However, you can sell any docked unit, including Tank-Bunkered units. Selling a Tank-Bunkered unit leaves the Tank Bunker walls up, rendering it useless. Selling the Tank Bunker then causes an Internal Error. Now, we don't want 'sell unit' forcibly resurrected, however it would be nice if either A) Tank-Bunkered units couldn't be sold (preferred choice), or B) Tank-Bunkers' walls retracted and the Bunker continued to work normally (second choice), or C) selling a 'broken' Tank Bunker did not cause an Internal Error.
| |
| *HarvestersPerRefinery - Make this usable
| |
| *A rules option so that units will consider in their threat scan neutral player-owned units that have a weapon or non-zero threat rating. It's so annoying if your mod has something that generates neutral infantry opponents that your units and, more importantly, the AI completely ignores.
| |
| *fix the "AI doesn't deploy MCVs with new locomotors set on them" bug(IE hover, jumpjet, subter...)
| |
| *Fix the Droppod Locomoter
| |
| *Force refresh when returning from game-mode menu to apply changes to the menu made by a game mode, such as money range, or starting units range.
| |
| *Tote action (carryall logic) and Heal action (negative damage weapon given to an infantry) need to point to sequences in mouse.sha rather than to the same single frame.
| |
| *If an AnimToInfantry call occurs for an animation that is positioned in a place where no infantry can land then the call will be suspended (potentially for the remainder of the game). This is believed by some to cause a general game slow down. Either way, it doesn't look nice. Perhaps the call could be cancelled if there is no space...
| |
| *{{tt|WeaponXTurretLocked=true}} "bug" when unit turns 180 the turret may spin in the opposed direction instead of following with voxle nit’s direction.
| |
| *{{tt|AccelerationFactor=0.01}}; This has a problem with voxel scales.
| |
| *{{tt|IsTrain=yes}}, {{tt|MovementRestrictedTo=Railroad}} one of these has the control for the train movement and the turn is 135 or 90 but the train should only turn 45 to prevent jumping tracks.
| |
| *in RA2 you can place a PKT with a map/maps in a mix, and rename it to an MMX and the map will work, like a map pack, however, the YR equevalant YRO(as documented by deezire) files don't actually work. my idea is to try and make them work!
| |
| *Improve the havester logic so it (the harvester) cannot go to an enemy base (and then get killed) when there is an Ore on it (enemy base)
| |
| *Factory Plant Settings reduce Solyent values to prevent income generation explotation. (If implemented, this should definitely be optional - I myself reduce soylents manually so I don't want them reduced further by owning an Industrial Plant.) By default vehicle refund should be 50%. Basically if you make a vehicle 25% cheaper, you should only get 50% of its value back
| |
| *Code the {{tt|Hospital=yes}} and Machine Shop tag so that owning multiple buildings does generate an undocumented cumulative effect.
| |
| *The game reads langmd.mix > missionsmd.pkt and uses it to determine which gamemodes the stock maps are available in. Editing this file and dropping it in the directory causes random bugs and duplicate entries in the map list. If possible, add a rules tag pointing to a filename to read ''instead'' of missionsmd.pkt (de-hardcode the reference, like the {{tt|IsIFV=}} and similar new tags do). Like {{tt|[General]}}-->{{tt|PKTFile=}} .
| |
| *A fix for the ridiculous slowdown caused by having an extra CD drive or too-good hardware. In my case, my P4 3.0GHz and GeForce 5900 are (my the sound of it) the two pieces of hardware that stop me running YR...
| |
| *Fix the currently unworking {{tt|CloakStop=}} tag
| |
| *Fix it so that your computer doesn't have to be in 16-bit colour for the windowed mode (from adding -WIN to a shortcut) to work, i.e. it supports 32-bit colour too.
| |
| *Make Fighters/Aircraft Cloakable with their own cloaking unit and can dogfight, ATA without {{tt|Jumpjet=}} or altering the height-fongsaunder
| |
| *Allow aircrafts/copters to transport vehicles correctly, not by setting a ridiculous ammount of transportable units. (ex: you'd have to set the Hind and the NightHawk to have alot of pips, about ten, just so one tank could fit in it)
| |
| *Allow rotors to work with Aircraft units (not just copters) correctly without any bug.
| |
| *Fix the error when having a gate that slides down (TS style) instead of opening sideways which made the gate appear OVER a unit passing on the downed gate.
| |
| *Fix it so that when you add a superweapon upgrade to a building that has a superweapon, it overwrites the previous superweapon, instead of just adding it as a new superweapon (perhaps make it an optional tag)
| |
| *Make {{tt|PrismType=}} support more than one
| |
| *Bring back mine layer codes
| |
| *Fix voxel size units that is bigger than a tank. Eg.: Like if you have a mech or walker unit that is bigger than a 1x1 square.Wish voxel size can be user define like {{tt|VoxelSize=2x2}},like what you can do for buildings.
| |
| *Enable the Robotic Centre to accept more than 1 robotic units and if it is destroyed and rebuilt,the robotic units that are more than the first one can be shaken out from their shut down mode. This should also fix a problem with mods that have Vehicle Hijackers and more than 1 type of Robot Tank.
| |
| *Enable a Psi-Warning animation for the intended target of any superweapon, not just the nuke and its clones.
| |
| *Make a unit ELITE with the armory should coast money, like EliteInfantryCoast=3000, armory is to cheaty right now
| |
| *Make so a [vehicletype] can spawn an othe [vehicletype]
| |
| *Fix the issues with the 'Dropship load screen' and alter its logic so it is possible to specify the units to use as the 'DropShip', preferably any type of unit, not just aircraft.
| |
| *<s>Make so a unit only can built by a specefic warfactory, like BuildOnly=HTNK(on the new warfactory) This is good so big tanks can spawn on a big factory</s> (see the [[RockPatch_talk:Wishlist#Re:_BuildOnly|talk page]])
| |
| *Make weapon that, when you fire a unit, you get extra hp, like ih Damage is 100, thats mean you take 100hp from them and add 100hp to you
| |
| *BUG: Flipping other tanks... If a tank is to heavy and cant be flipped, the heavy tank get permanetly emp and the tank with flipper weapon cant flipp other unit the heavy tank is dead(not rp bug)
| |
| *Fix so AI dont build more unit than the buildlimit
| |
| *make the tunnel system works(like generals that GLA uses)
| |
| *In game,when you press esc, there should be a OPTIONS button there
| |
| *Make a magnetic push weapon yhat pushes other vehicles away
| |
| *Subterrainean units that have occupants that can fire out of the unit like the Battle Fortress can fire at targets even when traveling underground.
| |
| *Repair bugs with DropShip load out screen and change cameo highlight to size of RA2 icons.
| |
| *Fix the dam hardcoded stolentech
| |
| *Make so Cyborg=yes can get EMP and is allowed to iron curtian protection and also make the make so iron curtians warhead is in rules.ini
| |
| *Give Aircraft the ability to fire at other aircraft. And if they already can, how?
| |
| *Enable the Auto-Deploy logic to work with human players. Currently it only works with the AI, human-controlled units are unable to use Auto-Deploy. This was apparantly either unfinished or desupported according to the ini files.
| |
| *Fix the harcdoed CourseLockDuration= and Level= in projectiles, so the unit can fire a bullet that goes in a strange line
| |
|
| |
|
| ==Done==
| | '''The other pages of this wishlist exist soleley for archiving purposes.''' |
| *Breaking of the 100-unit-limit
| |
This is legacy information, included here for historical purposes.
Attention!
This page is obsolete. Feature requests are now managed through the Issue Tracker.
How to request a Feature
Go to bugs.renegadeprojects.com. Click on Login. If you have an account, log into it. If you want to be informed about your request's outcome, plan to request several features, or want to report bugs later, click Signup for a new account and register; if not, click Login Anonymously. Once you are logged in, either normally or anonymously, click on Report Issue. If you didn't do so already, the system will ask you to select a project. Choose RockPatch2 and click Select Project. Now set:
- Category: Feature Request
- Reproducibility: N/A
- Severity: feature
- Product Version: empty
- Summary: A one-sentence description of your request - this is what will appear in the issue list, so if you want pd to actually read it, summaries like "ADD THIS PLEASE!!!1!!" are not a good idea.
- Description: A detailed description of your request - don't write novels, but the more details you have, the easier pd can assess the wish.
- Additional Information: What the title says - possibly a summarized list of the suggested ini flags or something like that. Anything you have in your head about your wish that doesn't quite fit into the request as such.
- Upload file: This is mainly used for bug reports, but if you did something like a photoshop mockup of your request, you could attach it here.
- View Status: Public
- Report Stay: If you wish to return to the report form to add more requests or bug reports, check this.
Afterwards, click Submit Report. Congratulations, you just requested a feature.
The Reason for this Change
On first glance, this new procedure may look a lot more complicated than the previous one, but check out what you get in return:
- Status reports - each request is a single item in the database with its own status information like priority, eta, status, etc., etc.; you won't just know whether pd generally works on your request, but you can see in detail how long he things it'll take, how far he is, and in which version it will be available.
- Comments - in the past, there were often opinions or improvement suggestions on wishes by other users. For reasons of order, commenting directly on the page was prohibited; on the tracker, this is not the case. As each issue has its own page, everyone can leave a note at the bottom specifically for that wish, giving his opinion or suggesting improvements for it.
- Roadmap & Changelog - with both feature requests and bugs tracked by the same system, said system can directly and immediately calculate how close to completion the currently worked on version is. No need to wait for updated wiki pages or forum posts - just check the percentage on the roadmap!
And that's just what you get out of it. For pd, it means a lot less management effort, and an easy way to quickly assess, prioritize and plan feature additions. When he dismisses a wish, it's marked as dismissed. When he chooses a wish, it's automatically on the roadmap. A cleaner environment for both sides, and less time spent updating ModEnc for pd.
The other pages of this wishlist exist soleley for archiving purposes.