ChristmasTree
Members
-
Joined
-
Last visited
Reputation Activity
-
ChristmasTree reacted toDeactivated Memberin [WIP] LAPD/LASD/CHP FPIU (2014)This is why I work alone.
-
ChristmasTree reacted to ItsFozzy in [REL] Cosmo's Lenco VariationWas playing around with the R* Editor and image editing with the Bearcat a few weeks ago :-)
-
ChristmasTree reacted toDeactivated Memberin My Thoughts on V ModelingNo, and ironically you're avoiding the point I just addressed earlier again. You fail to see beyond simply blaming the us as individuals for making that decision. I'm not failing to own up to any decision as it is my decision to do so or not, but you seem incapable of accepting that a decision is taken as a result of influencing factors. That being said, elaborating further will just be a repetition of what I've previously said and I'm not going to waste my time endlessly saying it over and over again when obviously it goes in one ear, gets filtered to your liking, and goes out the other.
Following your one-way logic would be like having a scenario wherein a bird shat on your head and in retaliation, you made a decision to shoot that bird. Though, when you're questioned on your motive behind the decision to shoot the bird, you cannot say that it was because the bird shat on your head.
-
ChristmasTree reacted toDeactivated Memberin My Thoughts on V ModelingOh please, spare the goddamn lecture. Interpret what I said however you want, but indirectly those in support and fighting for the whole unlocked-only idea will be responsible for the modelers not releasing anything if the ability to lock doesn't materialize. Its not as if these debates and the stir caused by all of those supporting this idea has gone unnoticed, they will have an impact. Anyhow, I can't help for the fact that you always attempt to stick the blame on us without looking at the bigger picture first(not that I'm at all surprised by it).
-
ChristmasTree reacted to Fartknockr in My Thoughts on V ModelingNormally, I don't ever reply to these topics or any topics unless they are requesting help.
Hystery,
I really do NOT understand why people keep doing these stupid topics with their opinion. NOBODY actually cares what YOU think. All they care about is what they think and what they want to happen. Making a topic and starting a flame war has absolutely no resolvement in the debate about whether or not Zmod3 should have a lock feature for V. We had the option to lock in Zmod2 for IV. There is absolutely no difference between then and now. All that is different, is people becoming with more greed because of the more Development Resources that the community has released. Mostly people are bitching because they don't want to wait several years after the release of V to have a vast amount of DEV parts as there is available for IV now, after several years. NOBODY had to release any development parts for IV, yet they did. People will do the exact same thing now with V.
Whining and Bitching to people about wanting things unlocked/given to you, will get you nowhere. It actually shows the modelers who happen to make these things, especially the DEV Parts how childish the community is. All you guys are doing is whining until mommy and daddy gives you what you want, or not at all and the arguments and tantrums still continue until you find something else to whine about. Either way, you move on. It's life. It's the modelers choice as to whether or not they decide to release anything unlocked or not; However, complaining about locked models, makes the modelers who do release quality mods, either not want to release it no matter what(locked or not), or never as a DEV part, and especially not here on LCPDFR since it's not supported.
If that's not good enough for you, put it this way: Just tell LCPDFR to release LSPDFR unlocked as open-source. Apparently everything for V should be unlocked, right? LSPDFR is for V. ...................... Exactly, they won't. Why? Because they took the time to create something of quality and wish to preserve it for the community they wish to keep it on. It's their choice as to whether or not they release it with open-source for the community. Again, they won't. Too many people would steal it and take complete credit for by making some single small minor change to it.
I'm on both sides of the fence; however, I'm more for the support of locking for V. I will not release any vehicles for V until there is support to lock. I've made over 60GB worth of skins. I'm not ever going to release anything because of the community wishing to steal and claim as their own although the issue gets taken care of quickly if it does happen (which is a lot, not surprisingly). I can see where people want access to wonderful mods that have been released, I'm the same way but I understand when someone wants it locked to prevent ripping and stealing.
In summary, quit the bitching and whining. It's not going to get you anywhere nor is it going to persuade the authors who create phenomenal mods, to ever release unlock. In the end, it'll actually make them release locked, no DEV parts, or nothing at all. I'd rather enjoy something of great quality that is locked than something of shitty quality that is unlocked.
-
ChristmasTree reacted to Cj24 in My Thoughts on V ModelingHonestly, I don't think anything is going to change. Instead of locking models, people simply won't give permission to edit them.
Just because all models can be edited, far from all models may be edited. The only thing that's going to be easier is to import models in ZMod. However, it's going to be a lot more complicated to check whether credits are correct or permissions were given. In the past, you were able to filter for unlocked models and you were allowed to use nearly all of them without any further permissions. Now you'll need to check every single model part to find out if you may edit it or have to contact the author to ask for permission.
Without the ability to lock models, there won't be a new "open source" modding community. There'll just be much more reports because people don't want others to edit their mods.
-
ChristmasTree reacted to Sam in LSPDFR 0.2 Delay Update - 13 JulyTo follow on from the previous update I posted yesterday, we're still hard at work preparing LSPDFR 0.2 for release. At this time, it would appear that all issues caused by the latest update to GTA V have been resolved. Indeed, I spoke of the problem and its solution in more detail in the previous update regarding 0.2.
Unfortunately we're still experiencing issues with LSPDFR 0.2 which appear to be unrelated to the recent update and more of a problem with the modification itself. These are in the form of script crashes that some, but not all, have encountered during pursuit testing and this is something we've been looking in to. Unfortunately this seems to be quite a tricky problem to find as different users are experiencing different results. Nonetheless, I'm hopeful that we'll find the problem and resolve it relatively soon.
While LMS has been hard at work debugging most of our issues (both the ones caused by Rockstar's protections and ones of our own making), I've taken advantage of the extra time to add more polish to LSPDFR 0.2, and even introduce a new feature which I know will be very popular. To complement the police computer in a vehicle, here's a sneak peek of the equivalent system on foot:
Bear with us as we work this out. I guarantee you that LSPDFR 0.2 won't disappoint.
-
ChristmasTree reacted to Sam in LSPDFR 0.2 Update - 12 JulyFirst up, we're all sorry for the problems we encountered with the release last night. Unfortunately, there was a game breaking performance issue which was found only a few hours before we intended to release and this has required some time to investigate.
The good news is that we've done our best to mitigate this problem, related to the way in which Rockstar has started to introduce anti-modding protections. For those of you interested in the technical detail, here's a snippet of a performance test ran by Alexander Blade and LMS:
Performance difference between GTA V version 372 and 393 Calling SET_CURRENT_PED_WEAPON 1000 times via ScriptHookV and RAGEPluginHook: 372: ~582ms (RPH: ~585ms) 393: ~2480ms (RPH: ~2490ms) Performance on version 323/350 is most likely even better due to even less/no obfuscation than 372.In short, on the previous patch (372), it took 585 milliseconds for the function to be executed 1000 times. On the newest patch (393), it took 2490 milliseconds, which is roughly 2.5 seconds, to be executed 1000 times. This means that this particular function takes five times longer to execute on the latest patch than it did previously. LSPDFR 0.2 and 0.1 call this function a lot, mainly to stop other police officers from killing suspects, as we force them to be unarmed when appropriate by using it. As such, during a pursuit with even a couple of units, performance takes a hit.
With the problem identified, we've managed to come up with an alternative way of doing things that doesn't have such a dreadful impact on performance. This version is currently undergoing testing, and we hope to be in a position to release 0.2 as soon as possible. Note that I won't commit to a date, as it is possible we run into further issues, and we'd like to avoid a situation similar to last night's, but there is still the possibility that we can release today, and we'll keep you updated as to our progress.
Sam.
-
ChristmasTree reacted to Sam in LSPDFR 0.2 - Stun Guns & MoreThis is the final part of our LSPDFR 0.2 preview series. For more information about the changes we're making with 0.2, take a look at the previous installments in this series, found here:: http://www.lcpdfr.com/forums/forum/880-news-updates/
LSPDFR 0.2 not only goes some way in addressing a lot of the feedback we received as far as features were concerned, but it also includes a large number of fixes for issues reported to us. A full list of these fixes will be published with the release, although among the things we sorted out are many of the frustrations people had with arresting, as well as traffic stop suspects reversing into players and the problems with detecting vehicles for traffic stops.
Aside from these fixes and the features we've already covered, there's still more to talk about. One of the big things that we saw people wanted was the return of the stun gun. Thankfully, with the inclusion of a stun gun in the game, this was quite an easy task unlike in LCPDFR. LSPDFR 0.2 introduces support for both the player and all AI officers to use stun guns. The AI support has been somewhat improved since LCPDFR 1.1, with more fluid animations and better mechanics in general thanks to the stun gun already being present in the game. Players are also now given a stun gun when going on duty, and we've been experimenting with AI configuration flags to make suspects tougher, so that they don't die after one hit - currently this works for all callout spawned criminals, and we hope to expand it universally.
Stun guns make their return in LSPDFR 0.2, with player and enhanced AI support. Shown is an AI officer drawing his.
One of the other main things that we've been experimenting with in 0.2 is audio. GTA V comes with a massive amount of police related audio which is fantastic, and we're looking to take advantage of this as much as we can. For 0.2, we've introduced a basic version of the Police Scanner seen in LCPDFR 1.1, with a couple of key differences:
The weird clicking noises between sounds have been drastically reduced. More variations of audio lines are present. You will now hear other officers talk on the radio too. Of course, this is still very much an experimental system and we'll be looking to make extensions and improvements in future versions.
As this is the final installment in this update series, instead of promising another article the next day, we'll promise something else: LSPDFR 0.2 - coming very, very soon.