-
Posts
245 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Downloads
Everything posted by Slimwaffle
-
Gamecrash; due to kill or respawn script changes something...
Slimwaffle replied to Kenneth Nyström's topic in Programming
What I ended up doing with my game was removing all the code that says what happens if the player dies. Then inserted my own code that says; teleport to respawn location, reset health, reset stamina, reset thirst, reset hunger, empty inventory. Using this method the player technically doesn't die but it simulates death. Then all you have to do is for your enemies is add code that makes thier target nil and tells them to search for new target. But as for your code the only thing I can suggest is set up a trigger value and then breadcrumb. So for example add something like; Script.trigger = 0 Then in your update world add; if self.health <= 0 then self.trigger = 1 end if self.health > 0 then self.trigger = 0 end if self.trigger == 1 then --Add the code here that triggers or references the change map. end -
Is it possible to tweak the nav obstacle feature maybe to extend the range at which it prevents you from stepping into the enemy?
-
wow half a mill in polys seems like alot. My game doesn't have any models that use more then 30k polys.
-
Thanks I got a temp fix by right clicking the published version and selecting the option that lets the exe handle DPI scaling instead of the system. But it still doesn't go to a true fullscreen because it has black bars now(that is on my gtx 1080). On my gt1030 which is a 2gb card everything works fine. I am wondering if there is an option somewhere in nvidia panel or windows that always allows the application to handle scaling.
-
The 1080 seems to be working amazingly. I just have an issue with it and leadwerks. Its something to do with higher resolutions and dpi scaling. I posted another thread in general about it. Leadwerks as well as my published game aren't going into full screen properly and giving off weird resolution numbers in the game's menu.
-
I need help guys. I am getting the weirdest bug. I replaced my gpu today to a better one. Now for some reason resolutions in my game aren't working correctly. The published to steam version and when I run it through leadwerks engine. Also full screen doesn't actually go full screen now. Its got to be some setting on my gpu. Because I haven't changed any of the games code. I am posting screens to show what I am talking about.
-
I ended up getting the 1080 because it was only an extra 100 from the 1070. I got to look at my game for the first time today not on low settings and was actually pleasantly surprised.
-
Hey guys I was hoping to get some advice with some physics issues I am having with Enemies in my game. Its been an ongoing thing for a while. So I am getting issues when fighting enemies in a melee fight. Something is happening where I think the player gets caught inside the physics shape of the enemy and this causes the game to crash. Is there anything I can do to prevent this or to push the player back outside the physics shape of the enemy?(To prevent this random crashing). Or even something I can add to the system to say when there is an error wait x amount of seconds before returning to normal functioning instead of crashing.
-
Thanks mate. I think I might go with the 1080. You pretty much confirmed what I was thinking.
-
So I am looking at upgrading my gpu specifically for building games. I want to get something that I can eventually use to make a VR game. What nvidia cards would you guys recommend for this? I was thinking a 1070 or 1080.
-
You guys wouldn't happen to know the ETA on turbo at all? I am hoping 64 bit will help my game. I have noticed massive fps lag spikes in my game whenever it spawns enemies. Oh and I just noticed I can sub to the beta. Will this add it in steam under my leadwerks app the same way upgrading to professional did?
-
I have noticed when I publish that my exe is 32 bit. Is there any way I can make my game 64 bit. If it isn't a feature what would it take for me to make it 64 bit myself. I would really love for my game to be able to access more then 4gb of ram. There was an option in visual studio to change everything to 64 bit but when I did this alot of the leadwerks commands just threw errors.
-
Thank you soo much guys. Absolute legends. Using this system of compressing sub-folders works perfectly. Now when I make a small change to the game it will only upload a few mb. Also using this system greatly reduces the upload time to steam after the initial build is uploaded.
-
Thanks heaps mate this was actually very simple. I simply had to add my text for password to one line of code and then zip everything up myself. I will let you know how it goes with the uploads. Uploading to steam takes a really long time.
-
Do you possibly have a link? Using search gives me alot of stuff to filter through.
-
So I tried this and it worked great for fixing the patch sizes. But doing this way offers like no file protection. Steam say they encrypt files. But I can't see any evidence of that. Is there a way to keep my file protection and fix the patch sizes? So I had a look into how other games on other engines do it. And I think I came up with a middle ground that would work. But I'm not sure if its possible to do on my end. So I noticed other games create package files. These act almost exactly the same way as the data zip file created when I use the publish standalone feature in leadwerks. What I would like to do if possible is configure the leadwerks publish feature so that instead of creating a single encrypted zip file for all files in the project. It creates one for each of the sub folders in the main folder. For example, (My project Folder is called Waffles) configure it so that it creates a zip for; Addons folder, Prefabs, Scripts and so on and so forth until it has everything contained in a subfolder in an encrypted/compressed zip of the same name. That way when patching; Steam says that it can't scan any folder that is encrypted or compressed. But it should only replace the ones that have changed in size. Because it replaces folders and files that have changed in size. Is this possible? And would it even work?
-
Thank you so much mate. Massive help.
-
ok because when I generate a build using visual studio to a folder on my desktop it just adds 3 files. Waffles.exp, Waffles (Application) and Waffles.lib So then I can add the rest of my project to this folder? And I just remove all my scripts? Because they are all in lua and the cpp files just launch them using the Interpreter. I am just unsure of which files you are referring to when you say Source code files.
-
So with C++ I only have to include the exe?
-
yeah ok. So my next question is how would I publish if I wanted it to use c++. Is that something I do through visual studio?
-
How would I do this? Publish first and then replace the data folder with an uncompressed data folder? That way I have the extra files and the exe as well.
-
So I found what I think is a bug. My game that I uploaded to steam and is for sale on steam forces the customer to download the full size of the game whenever I upload a new build. It shouldn't be doing this because steam should scan the game files and determine which ones have changed. Then I came across something interesting in the steamworks documentation saying that if the game uses encrypted or compressed files/ folders steams scanning won't work. And I know that when I publish with leadwerks standalone that it compresses the game files/folders to a zip file. Is there a way to make leadwerks not compress /encrypt these files. Because customers downloading the full game each time is excessive. Here is the info from steamworks; Building Efficient Depots for SteamPipe The old Steam content system would patch updates on a file level, which meant that if a single byte in a file changed, the entire new file would be downloaded by all users. This was especially inefficient if the game used pack files, which are collections of game content files in a single big file. Pack files can easily exceed 1 GB, so updates often led to unnecessarily large downloads. A common way to avoid these large downloads was to add new pack files that overrode content of already shipped pack files. That worked for updates, but it hurt new users long-term, since they ended up downloading unused, already-patched content. The new content system fixes this problem by splitting each file into roughly 1-MB chunks. Each chunk is then compressed and encrypted before being distributed by the Steam content system. If the game content has large redundant parts, these chunks are reused and the user only has to download each repeated chunk once. However, the real strength of this system is building efficient update patches. While the system is building a patch, the new content is scanned for already known chunks. If it finds them, it reuses them. This means if you change or inject a few bytes in a big file, the user only has to download the changes. This works well in most cases, but there are still a few pitfalls that need to be avoided when designing the content layout of a game. Do not compress or encrypt your game data. This is already done for in-flight downloads and retail discs by the Steam content system. If you do it too, you will reduce the effectiveness of delta patching. If you package multiple data files in a single pack file, make sure that with each re-packaging, no unnecessary changes are made. One problematic practice is including the full name of the original source files on disk, because the names may change, depending on the build machine. Another bad pattern is including build time stamps for each file. If possible, always add new content to the end of your pack files and keep the order of existing files. Also, keep your pack file’s metadata (offset and sizes to individual files) in one place and don’t intersperse it with content files. Use a binary diff’ing tool like BeyondCompare to look at two builds of your pack files to make sure that hundreds of unwanted changes don’t show up. If you follow these rules you will minimize patch sizes and only new content will need to be downloaded. Your customers will thank you for that and you will be able to increase the quality of your product by shipping more updates.
-
I did this but the button still isn't printing to the system.
-
Hey guys. I need help on this one. I am trying to create a script for storage containers in my game. So far I can walk up to the container, Press Use and it launches a GUI. But for some reason I can't get the button to work. I can click on the button. But it doesn't process button events. To print the command to the system. I will paste my code below. test1 = 0 function Storage() local Storage={} local scale = 1 --GUI gui = GUI:Create(context) gui:SetScale(scale) local widget Storage.gui=gui Storage.context = context gui:GetBase():SetScript("Scripts/GUI/Panel.lua") Storage.but1 = Widget:Button("Testing",10,20,80,30,gui:GetBase()) gui:Hide() function Storage:Update() self:ProcessEvent(Event(Event.WidgetAction)) while EventQueue:Peek() do local event = EventQueue:Wait() if self:ProcessEvent(event)==false then return false end end return true end function Storage:ProcessEvent(event) if event.id == Event.WidgetSelect then elseif event.id == Event.WidgetAction then if event.source == self.but1 then System:Print("Button Working") end end return true end return Storage end function Script:Start() Storage() end function Script:Use() test1 = 1 gui:Show() Time:Pause() mlook = 1 context:GetWindow():ShowMouse() end