Jump to content

Oddly

Ascending Contributor
  • Posts

    480
  • Joined

  • Last visited

  • Days Won

    35

Oddly last won the day on October 19

Oddly had the most liked content!

6 Followers

About Oddly

  • Birthday 01/02/1995

Contact Methods

  • Website URL
    https://www.github.com/DylanDodds

Profile Information

  • Gender
    Male
  • Location
    Orange Park, Florida
  • Interests
    Shoving kittens in a blender and listening to the scream for sweet mercy.

Profile Fields

  • My Project
    Machine Learning

Recent Profile Visitors

176,762 profile views
  1. Don't, whatever you do.

  2. Whatever, don't you do.

  3. Anyone else carve any sick pumpkins for haloween this year?
  4. Whatever you do,

    don't.

  5. To be fair, database migrations are always difficult. I work similar database implementations at work in C# as they use in intersect, we tried migrations out for a while, I guess the developers before me decided to stop keeping up with it in our api, because we dropped support for automatic migrations. And as far as making copies and backups of databases, Its pretty standard in the industry to have a seperate development database that is a clone of your original. I've worked on projects with 3 different environments, dev, staging, and production. Production is of course the client use, staging is when we need to show of code to the client that is ready to be deployed to production, you can imagine it like a beta, and then dev is to development on.... Oh and I guess we had a QA too which was for our QA department to test our code.
  6. Most linux systems (not all) use systemd to manage services. This can ensure persistence of your server so if it crashes, it will automatically be restarted, you can also use systemd to ensure the service runs under a certain user so the app is limited to certain permissions, and restricted to their own environments within linux. Systemd allows us to manage services as well with console commands like `sudo systemctl stop <service>` `sudo systemctl start <service>` `sudo systemctl restart <service>` `sudo systemctl enable <service>` - ensures if the system restarts, the service is started back up automatically on boot. `sudo systemctl disable <service>` `sudo systemctl status <service>` - check whether a service is successfully started and running Assuming you are using a debian based distribution such as ubuntu, I garuntee your system is likely using systemctl. I use Manjaro linux which is arch based and it uses systemctl too. Here is a link for setting up services using systemd to sort of point you in the right direction. I'm sure you can find a tutorial that suits your distribution best. https://medium.com/@benmorel/creating-a-linux-service-with-systemd-611b5c8b91d6 Systemd also uses journald for logging, so any errors your service throws will be output into your system's journal. I recommend reading a bit up on how that works and what other capabilities systemd holds
  7. I have found personally reverting database migrations can be a bit of a nasty process. Always back up your DB and have something separate to work on in your development environment. If something happens to your db in your dev environment, you can manually delete the migration file (if I remember right its a generated .cs file. The name is auto generated I believe). If you mess up a database during a migration, just delete it and revert back to your backup copy, fix the mistakes you made, and rerun the migrations in your backed up database. The databases are the .db files in your resource directory on your server. Never use your production databases in your dev environment. Deleting or damaging your DB files will delete game and player data. If you need game data that is in your production environment, copy your db files over to dev environment. I think intersect supports mysql too, i dunno if you're using it, but if you are setup a development mysql server to work on. The process for backups and recovery with mysql is a bit more of a hassel, and I don't know all the steps to explain it off the top of my head, but there are guides online for it. On actually fixing your issue, you are going to need to go in with an sql browser and edit your database files manually and undo whatever the transactions did manually, and then manually delete your migration. I don't know what you did in your migration so i can't tell you exactly what you need to do to fix it. DON'T FORGET: Make a backup of the already damaged db files in case you damage them some more trying to manually fix it
  8. I know, but the thought also came to mind that, If the end user is using a machine with processor that doesn't support on board graphics, the GPU may take care of the drawing in GDI+. And if not the APU may have similar limitations as well. I wasn't sold it was the texture size issue, I was just trying to ensure it wasn't.
  9. I wanna say an RTX 3060 should be able to handle resolutions of up to 4k. I see people using the card for NVidia CUDA with 8k x 8k resolution, but will say 16kx16k resolutions are too big. Of course, I don't know if those CUDA limits are gonna be the same for rendering limitations. It appears to be loading an image from file last before It crashes, so I doubt its your Map's texture size. If the map's surfaces gets created just fine, even if there's no data in it, its likely not the size of your map's texture here, because the space for the texture would likely already be stored in memory at this point, or not created yet. If no one's able to resolve this by tomorrow night, Hit me up on discord and maybe I can help you figure out what file is causing issues OddlyDoddly#2354
  10. Technically what I posted is a GPU limitation and can apply to all graphics rendering libraries, not just monogame. I've dealt with the same issue in OpenGL. That being said, what panda shared is likely possible too. Ensure all your tilesets are in the acceptable image format (I think its PNG), and ensure you're able to view all the resource files in a normal image viewing program. If they don't open they're probably corrupted. Can you list for me the following information: What processor is in your machine, What graphics card you're using, Give me the dimensions (in pixels) of one of the larger texture files you're trying to load. I can tell you if this is a GPU limitation
  11. So I was looking up monogame's limitations to see if the texture size limitations, because after JC mentioned something, I remembered that GPU's sometimes have a maximum texture size permitted for objects. The max limit on the size of a texture being loaded can vary by the graphics card. Some graphics cards will support up to like 16384x16384 pixels, I've personally dealt with this when coding before where the graphics card I had at the time didn't allow 4096x4096 images. Do you have any sprites, tilesets, new graphics, even GUI that you've added recently that might be on the large size? Here's a thread I found on monogame regarding the topic: https://community.monogame.net/t/does-monogame-not-allow-large-textures-like-20-000-x-1-000/7680/5 Also, what graphics card are you using?
  12. Are you editing the source at all? If you're running this through visual studio, do you think you can show debug data like how much memory you're using over time. If you're not in visual studio and just running the client, Resource monitor can track resource usage of specific applications over time. This information can be helpful for debugging. https://resource-monitor.en.softonic.com/ Even showing us some memory usage over time through the task manager might help.
  13. *Enters multidimensional space*

×
×
  • Create New...