JeepRubi
Former Developers-
Posts
1682 -
Joined
Personal Information
-
Allegiance
Nod
-
Location
Canada
- Website
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
JeepRubi's Achievements
Newbie (1/14)
2
Reputation
-
-
- sniperrifle
- weapon
-
(and 1 more)
Tagged with:
-
Rx_Mutator_SBHSniper View File * This is an example of how to modify default player inventory. * This mutator replaces the primary weapon of the StealthBlackHand with a Sniper rifle. Version 1.0.0 Rx_Mutator_SBHSniper.uc Rx_Mutator_SBHSniper.u Submitter ukilleddanny Submitted 01/05/2017 Category Modifications
-
Version 1.0.0
1081 downloads
* This is an example of how to create a mutator that can be triggered with the mutate command. * This gives the player a sniper rifle when they type "Mutate Sniper" into the commandline. Version 1.0.0 Compatible with Renegade X v5.271 Mutator : Rx_Mutator_GiveSniper.uc (Download) Source : Rx_Mutator_GiveSniper.u (Download) -
Rx_Mutator_GiveSniper View File * This is an example of how to create a mutator that can be triggered with the mutate command. * This gives the player a sniper rifle when they type "Mutate Sniper" into the commandline. Version 1.0.0 Compatible with Renegade X v5.271 Mutator : Rx_Mutator_GiveSniper.uc (Download) Source : Rx_Mutator_GiveSniper.u (Download) Submitter ukilleddanny Submitted 01/05/2017 Category Modifications
-
Sorry, I haven't been active lately. Will update now. Edit: Okay, it's up now. For anyone who want's to have their banners added, or change their server's IP, or image, you can send me an email, or get ahold of me on skype. You can get my contact info here: http://www.martinpalko.com/about/
-
Hey, Havoc just pointed me to this topic. I've actually made changes to the pawn and anim tree that will be in the next patch. There's a "run speed multiplier" variable that can be set to increase or decrease the pawn's move speed from the default by a percentage. It's made specifically to be modified dynamically for powerups/mutators. (I implemented for a speed upgrade crate) Your best bet would just be to hang tight until the next patch is ready.
-
I poked around a bit, and it looks like we should just be able to add it like any other page. I'm not familiar with the workings of how categories/portals and all that work, so it might be a good idea to contact the mods of the wiki to have them set it up "properly".
-
Yea, It's not really so much a problem of "not possible" but "not intended". It could definitely get modified to work properly with multiple buildings of each type, ideally finding/checking buildings would be all done through the Rx_Game or a helper class, instead of manually checking the level for them. It's just a matter of someone spending the time to re-factor and then test the changes, but imo, it's not something that's really high priority. (Altho it would definitely be cool)
-
Do we have a portal there? I had thought we'd need to make one. What's the link?
-
The thing is, a lot of players won't view/read a tutorial no matter how simple it is. I put together the one-page overview screen that is currently being used for the loading screen, and was originally on the installer, and the pause menu. A lot of players didn't pause the game to read it. Many new players have their hands full just trying to get their heads around c&c mode in general. No matter how good of a tutorial we provide, we can't guarantee that new players will read it, but should that mean they don't deserve to play the game? Of course not. Bottom line, is that you can't expect everyone who plays on a public server to be aware of the ins and outs of a game, or even speak the same language as you. That being said, we definitely could offer a lot more information to new players. As Rypel said, if there were a good community made tutorial, we'd be behind that completely. Maybe it would be possible for us to modify the mechanics of the mine limit somewhat to help alleviate this problem? Maybe instead of the first mines to be placed being the first to dissapear, ones that are placed in groups larger than a certain number, or furthest from the base disappear first? It could also be possible to display a warning message of sorts on-screen to a player if their placing mines is removing old mines. I'm sure that alone would be a great way to educate a lot of people, as well as remind others who know, but may not be paying attention.
-
Think about the bigger picture guys. Instead of being hostile towards players mining incorrectly, why not try and educate them? In the long run, what's is it that is really ruining the game more? Incorrectly placed mines, that might change the outcome of a single match, or driving away new players, and having empty servers?
-
It could do, but again, it's entirely untested, and when they were programmed, it was with the assumption that there would only be one, so expect that some things might not work properly
-
Yea, when the buildings were implemented, it was assumed that there would only ever be one of each in the map. There is also a LOT of code all over that manually searches through actors in the level for a building of a type, and then does logic on the first one it finds, like checking it's health or status. The one it finds is arbitrary, so having two of the same building could cause unexpected behavior in a lot of things. For example: -The purchase system could use a foreachactor() to search through the buildings, and find a war factory, then check it's health. If it's dead, then is could say vehicles aren't available. It could stop at the first one it finds, so the "first" war factory dictates if the purchasing system works, while the seconds one does nothing. -The HUD could again, loop through each actor, and for each one it finds, check the health, and if it's dead, disable the hud icon. If it doesn't return after the first one, the last one it finds will be the final value it sets, so on the HUD, the icon is tied to the "last" war factory in the map. So yea, ideally the code would take this sort of thing into account, and be setup to handle it, but that's unfortunately not the way it was implemented. I would strongly recommend against using more than one building in a map, because it's untested, and will most likely have some weird behavior. It may look like it's working on the surface, but there was never any "standard" way of accessing the buildings implemented, so each feature programmed by different people does it differently, and thus, may react differently when the original shared assumption that there was only one of each is wrong.
-
As for the K/D argument. That's something I've been thinking about since Beta 2. My thought would be to keep kills as it is, but replace the deaths stat with Vehicle Kills. The maybe have the displayed K/D ratio take into account vehicle kills, and possibly vehicle deaths. It would de-emphasize K/D by not showing deaths on the scoreboard, as well as reward vehicle combat.
-
And yea, that error looks like it doesn't know what Rx_InventoryManager is, so double check your package is compiling after RenX_Game.