Jump to content

PeaceMaker

Member
  • Posts

    413
  • Joined

  • Last visited

  • Days Won

    4
  • Feedback

    0%

PeaceMaker last won the day on November 29 2018

PeaceMaker had the most liked content!

About PeaceMaker

Informations

  • Gender
    Female

Recent Profile Visitors

4269 profile views

PeaceMaker's Achievements

Proficient

Proficient (10/16)

  • Reacting Well
  • Dedicated
  • Very Popular Rare
  • One Month Later
  • One Year In

Recent Badges

143

Reputation

  1. Is this on master branch already? if not, do you plan to release a development branch so people can also assist?
  2. Kurlz/kurc is skilled but unreliable and this is not news, it had been the case for years now (last used in 2023). If you have the patience to work with him, you will get good results but your project will probably suffer from it
  3. Sorry that you were forced to release it but also thanks I guess? mixed feelings
  4. This is pretty nice! I wonder how long it takes to compute a path like that and are you running it on the server side I'd assume?
  5. Genuine question, what kind of systems are you selling that requires a license?
  6. It's not year 2013 anymore, everything has been answered already and your report is missing so much details ...
  7. You are absolutely right, it isn't related to 64bit but seems more like a side effect after porting to 64bit ... I'm pretty sure I haven't touched that part of the code and gitlense can vouch for me I guess you never had these issues as you had modified the original rendering code prior to porting. Anw, you were right, instances with type TREE_OBJECT were never appended to PCBlocker list so still a mystery how this stuff worked before. Thanks for your input again
  8. Thanks for your reply. I've only showed the tree but this is also happening for normal objects... I just had the time to look at it again and added a bit more trace and I couldn't find anywhere that CMapOutdoor::RenderPCBlocker() was called from ... then I also looked at the code prior to 64bit upgrade and guess what it's also not called anywhere. Calling CPythonBackground::RenderPCBlocker() from CPythonApplication::RenderGame() makes buildings work again but not trees... So it could be possible that trees are indeed not flagged as PCBlockers as they don't get hidden either. So I cannot really explain how the hell that worked before, maybe you have some clues? Edit: I also checked that "RenderPCBlocker" is not called from the python module "background"
  9. 32bit https://prnt.sc/0HVuFxI_ffLd 64bit https://prnt.sc/jDIoSRWUUCzu I haven't really touched that part of the code so I'm a bit surprised why it would stop working.
  10. Did you by any chance experience any issues with "PCBlocker"? It's basically when your camera view hit an object and it's rendered with a lower opacity
  11. Don't think there's anything wrong specifically with this community. That's just how the world works ? If you're not open for critics then you should probably not make something public that you cannot defend... I understand that it's made for designers but you're giving them false hopes.
  12. If any client is able to load your "encrypted" files then granny preprocessor would also load them and that means you can reexport those models without whatever encryption you're adding to those files.
  13. Whats the point of the GR2 "encryption" if any client can read the "encrypted" files?
  14. Seems like what you implemented is half working, if people are able to get to character selection then auth port forwarded properly, you just need to do the same for all other ports used by your game. Have a look at CONFIG from each channel/core
  15. Using since 2019 and no issues so far ?
×
×
  • Create New...

Important Information

Terms of Use / Privacy Policy / Guidelines / We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.