Open RobinHood70 opened 8 years ago
The mouse calibrations for stretched windows should already be implemented. Although doesn't account for people putting mouse cursor over gems in 1C instead of 1A On Dec 11, 2015 12:13 PM, Robert Morley notifications@github.com wrote:To Do
Shorten combo boxes to fit inside client area Implement "amp" specs by altering name only (e.g., 000004 use with mg000032 (growth))
Bonus: follow color/effect choice when linking to amp gem (e.g., use with oc000004 or lc000004)
Consider for Future Versions
Advanced menu option that re-does current menus to allow combines, amps, and omnias (lots of coding involved) Auto-throttle based on ARGB/HSL of small rectangle/X points under cursor (wait for empty From on combine and non-empty To on Dupe) Mouse calibration for stretched or otherwise unusual window sizes (request click in 1A and 12C, then do calculations)
Bonus: allow for screwup of clicking in 1C and 12A (not hard, just use Abs math for most of it)
—Reply to this email directly or view it on GitHub.
Survey for GES specces, if you have some data, please post there: http://steamcommunity.com/app/296490/discussions/0/487876568227032402/
Updated top post
@CooLTanG: I’ve had it fail at least once using the Flash Projector, where it was clearly the slot positions that were the problem. I want to do more research to determine exactly when it fails, but the manual calibration would be for the edge cases like the one I encountered.
Ah yes flash version would fail, steam one works On Dec 11, 2015 2:51 PM, Robert Morley notifications@github.com wrote:@CooLTanG: I’ve had it fail at least once using the Flash Projector, where it was clearly the slot positions that were the problem. I want to do more research to determine exactly when it fails, but the manual calibration would be for the edge cases like the one I encountered.
—Reply to this email directly or view it on GitHub.
Updated top post
Me too! :)
GES recipes status:
The first batch is in (1687e8fc2b89540508e0e7), the file format will be the same as any other spec.
gemforce internally finds them by setting damage of bbound and red to 0 and then going on normally. This grants the same results of an enhancement of x10 onward, and I liked it more than setting an arbitrary enhancement factor. gemforce also forces the red to be added in a (b+r) gem, to allow folding of the hitfarming gem.
ISSUES THAT HAVE TO BE SOLVED:
1) The power is not the same of an ordinary killgem, even going with the same choice of gemforce will need us to change some values in the basegems. Same goes for all the derivatives of the base stats, but that should be automatically taken care of.
2) Every spec has a (b+r) subgem, but the player will put in A3 a br gem already made. Can we change (o+b)
in x
on the fly? And add some meaningful names for x
?
Clearly, we'll need an help page for GES things.
Hey guys, signed up here to let you know - when using latest release (1.0.8) and low delay (50) in a windowed fullscreen (windowed game, but maximised) the combiner acts erratic - resulting gems cost much more than their counterparts done when game window is either maximised and fullscreen OR when its windowed and with its default size. Oddly enough, raising delay to 250 seems to fix the issue One more thing - have you guys considered using amps/towers/traps for recipes bigger than 36 as an external memory of sorts? Putting 6 by 3 amps in the game area would grant additional 18 slots for bigger recipes to run without forcing additional moves and thus elongating the process - Ive heard from Bilbo that the next release will squeeze 70 slot recipe into 36 slots, at the expense of recipe taking 2 hours to complete :P Using amps for extra slots could prevent that. I imagine you could configure them by selecting bottom right and top left amp to let the program know where youve put them, and how many of them there are. It would require some toying with translation from the build-in 36 slots to external slots, plus duped gems would still appear in the original slot area. Just something to consider, if anybody can be arsed to code that.
Hi BinjiIsNotAmused,
Using buildings as extra slots is on our list for future consideration (https://github.com/gemforce-team/wGemCombiner/issues/21), but is a bit harder than it seems for the very reason you mention: duping gems is no longer straight-forward, and you have to make sure you leave base slots open to duplicate to, then move those gems into buildings before you need to duplicate something else.
We’re aware of the issues with 1.0.8 and have fixed most of them for 1.1, which should be out shortly. If the delay is the only issue you’re having, then you’re probably setting the delay too low. Steam, especially, requires fairly high delays once you’ve got a lot of things on screen, though even the web versions can require some fairly high delays themselves. For Steam, I’ve sometimes set it as high as 500ms as a precaution. That puts a lot of the really high-level gems out of reach, but when you get right down to it, the difference between a mid-level gem and a high-level gem isn’t all that large anyway. If you took a look at the link above, you’ll also see that an auto-throttle is on the list, which, if I can get it working, would pretty much eliminate the need for a delay and would ensure that the combiner goes as fast or slow as it needs to. I don’t know how viable that is, though.
From: BenjiIsNotAmused [mailto:notifications@github.com] Sent: December 16, 2015 8:51 AM To: gemforce-team/wGemCombiner wGemCombiner@noreply.github.com Cc: Robert Morley robinhood70@live.ca Subject: Re: [wGemCombiner] To Do List (#21)
Hey guys, signed up here to let you know - when using latest release (1.0.8) and low delay (50) in a windowed fullscreen (windowed game, but maximised) the combiner acts erratic - resulting gems cost much more than their counterparts done when game window is either maximised and fullscreen OR when its windowed and with its default size. Oddly enough, raising delay to 250 seems to fix the issue One more thing - have you guys considered using amps/towers/traps for recipes bigger than 36 as an external memory of sorts? Putting 6 by 3 amps in the game area would grant additional 18 slots for bigger recipes to run without forcing additional moves and thus elongating the process - Ive heard from Bilbo that the next release will squeeze 70 slot recipe into 36 slots, at the expense of recipe taking 2 hours to complete :P Using amps for extra slots could prevent that. I imagine you could configure them by selecting bottom right and top left amp to let the program know where youve put them, and how many of them there are. It would require some toying with translation from the build-in 36 slots to external slots, plus duped gems would still appear in the original slot area. Just something to consider, if anybody can be arsed to code that.
— Reply to this email directly or view it on GitHubhttps://github.com/gemforce-team/wGemCombiner/issues/21#issuecomment-165111190.
Oops, just noticed now that I'm on the thread on the web, that I was actually replying to the very thing I linked to. :)
Not really a problem. @RobinHood70 you were silent for several days, is everything alright?
Yeah, just going through a bit of a bad spell. I've been watching replies, but had nothing to say to them, really. :)
I added combo handling in the last commit. It's a bit rough, but the basic concepts are there. Not sure if this is the best approach or not, but it seems better than shuffling off different recipes to different locations. We can change if need be. Also need to deal with the fact that we have duplicate recipes deliberately now (e.g. "y").
I'll have a look. Reach me in chat if you want to discuss.
On an unrelated topic, deleting the user's input just because they wrote "ob" seems a tad harsh.
Hadn't thought of that. I'll fix it tomorrow to not change the contents if there's an error. If there's anything else, send me an e-mail or just catch me tomorrow. I'm still a bit off my game and not very clear-headed at the moment.
I fixed it in 3c4e5ff.
I still stand by the idea that we should have 2 separate dropdowns for gem specs and amp specs, the current seems very confusing and cluttered.
Take care.
Hey, IDK if I can reply to your reply (haha :]) so Ill just write it here - the issue I seem to have with combiner appears only in windowed fullscreen mode - windowed mode in default resolution and borderless fullscreen seems to work fine (at least I wasnt able to replicate the issue yet, perhaps with more mobs on screen but thats different thing).
At first I thought its resolution related issue - top bar of the windows and Windows task bar at the bottom change the actual resolution of the game, without changing the resolution of the window (still the same as with full screen). BUT whats weird - increasing delay fixes that for windowed fullscreen.
Simple solution? Add note to how-to, that program should be either used in borderless fullscreen or windowed mode, but not windowed fullscreen.
About external amps - guess its not most pressing matter, but I guess the gems put in them should be the least used ones (that would require recipe analysis, which gems are the least used (aka involved in least combines but also appear early and just take up space in the default combining area).
Auto-throttle sounds great, but how would you measure if the program is going slow enough not to make mistakes?
Side note - are there managem recipies better than 1024? Or is the difference between 512 and 1024 already small enough not to bother with 2048 (or higher) recipies?
Added line breaks to https://github.com/gemforce-team/wGemCombiner/issues/21#issuecomment-165429088, so I can actually read that wall of text, @BenjiIsNotAmused , next time write in a comprehensible way.
It's not "weird", the combiner picks up the resolution automatically and correctly, the problem is that the game lags more in true fullscreen, which is something we sure can't fix.
The delay is there for this exact reason, so you can do some trial and error and use the smallest one that doesn't screw up, as everybody's lag level is different.
I'm not sure about what are you trying to say about amps, really.
Auto throttle would work by querying the pixel color in a slot and understanding if there's a gem or not. Easier said than done.
Side note: yes, up to 2048.
"It's not "weird", the combiner picks up the resolution automatically and correctly, the problem is that the game lags more in true fullscreen, which is something we sure can't fix." Well, thats not what I wrote. I wrote it lags more in windowed fullscreen :]
About amps - just thinking aloud about (possibly) using amps as additional slots while combining.
About auto throttle - I was thinking about something similar, but it could cause more lag in the long run, if you'd probe the game every time gem is duped or combined as image processing usually takes a while to do... Changing resolution would mess it up too if youd want to compare color of background with no gems with current color of each tile as background stretches. Youd need to check background color levels for every tile separately so you can compare it after every action. It would also require additional actions - moving cursor to area where you expect to see duped gem to see if it duped, even if you dont need to use it right now - additional work...
I thought about something bit easier to do - some sort of 'calibrate' or 'check delay' (or whatever) button, which would run some low-level recipe with default setting, lets say, 3 times, so you could compare the results - if all three resulting gems are the same, the delay is fine, else>repeat the test with higher delay. Guess you can just do it manually, but doing it automatically would be faster. Maybe Ill toy with the idea myself if I have a while, tho Im no good with C# EDIT: Thinking about it - in fact comparing gems could be done automatically if youd be able to take a screenshot of game area. Just screenshot first gem, swap it with second gem, screenshot it, swap with third, screenshot it - this way the only differing thing should be mana cost if there were some mistakes in the recipe. Compare three screeenshots and see if theyre the same. Tah-dah.
Graphics processing can be slow, yes, but compared to the speed of combining, it's probably irrelevant. The only way to know for sure would be to try it. Changing resolution might cause minor problems, but given that the program already compensates for resolution changes, it's probably not that big of a deal. I've done very preliminary research into it, and it doesn't look like you'd actually have to move the mouse. There's a function, BitBlt, that returns the colour for each pixel in an arbitrary rectangle, so it would just be a matter of doing that and then figuring out a fast but functional parsing method for whether it's the stone-like background of an empty slot or a more colourful thing that would represent a gem. The question is whether that's easy to distinguish when you're looking at combo gems with black in them, which might be dark enough to be mistaken for background. I won't know until I try, if I ever get around to trying...graphics parsing isn't a strong suit.
The problem with the kind of manual calibration you suggest is that in the short term, GC may well keep up, even if the delay is set too low. In order to truly calibrate, you'd have to run longer, more expensive combines. Also, the delay varies significantly between versions and with how much is on-screen. On an empty screen using the standalone Flash player, I can use delays of as little as 10ms, and the game will more or less keep up. Once there's thousands of monsters on-screen, the delay decreases significantly to about 50-60ms or more if it's super-crowded. On the web and Steam versions, delays are much higher than that on average. I'll have to look into your report of different windowing/fullscreen settings making a difference, but I suspect there'll be nothing to be done short of auto-throttling or each person guesstimating delays for their specific setup.
Also, comparing gem screenshots won't work because the game introduces randomness into it. The colours of the gems change, as do their damages. I suppose you might be able to focus in on the level indicator or upgrade cost or what have you, but if you're gonna do that anyway, you might as well auto-throttle...at least assuming the speed is reasonable.
To get away with lag I pause the game and combine. If there is no shadows on screen I can even put it at 0 ms and it runs fine. This is with a windowed steam version, which runs much smoother the smaller you make the window On Dec 17, 2015 1:33 PM, Robert Morley notifications@github.com wrote:Graphics processing can be slow, yes, but compared to the speed of combining, it's probably irrelevant. The only way to know for sure would be to try it. Changing resolution might cause minor problems, but given that the program already compensates for resolution changes, it's probably not that big of a deal. I've done very preliminary research into it, and it doesn't look like you'd actually have to move the mouse. There's a function, BitBlt, that returns the colour for each pixel in an arbitrary rectangle, so it would just be a matter of doing that and then figuring out a fast but functional parsing method for whether it's the stone-like background of an empty slot or a more colourful thing that would represent a gem. The question is whether that's easy to distinguish when you're looking at combo gems with black in them, which might be dark enough to be mistaken for background. I won't know until I try, if I ever get around to trying...graphics parsing isn't a strong sui t.
The problem with the kind of manual calibration you suggest is that in the short term, GC may well keep up, even if the delay is set too low. In order to truly calibrate, you'd have to run longer, more expensive combines. Also, the delay varies significantly between versions and with how much is on-screen. On an empty screen using the standalone Flash player, I can use delays of as little as 10ms, and the game will more or less keep up. Once there's thousands of monsters on-screen, the delay decreases significantly to about 50-60ms or more if it's super-crowded. On the web and Steam versions, delays are much higher than that on average. I'll have to look into your report of different windowing/fullscreen settings making a difference, but I suspect there'll be nothing to be done short of auto-throttling or each person guesstimating delays for their specific setup.
Also, comparing gem screenshots won't work because the game introduces randomness into it. The colours of the gems change, as do their damages. I suppose you might be able to focus in on the level indicator or upgrade cost or what have you, but if you're gonna do that anyway, you might as well auto-throttle...at least assuming the speed is reasonable.
—Reply to this email directly or view it on GitHub.
Hey, I wanted to toy a bit with BitBlt just to see how long capturing and processing single frame would take, to see if using it for auto trottle makes any sense but... I feel Im too dumb with Windows applications. Ive created new C++ project to try out this example https://msdn.microsoft.com/en-us/library/windows/desktop/dd183402%28v=vs.85%29.aspx , figured out how to deal with "stdafx.h" and #include "GDI_CapturingAnImage.h", still getting errors tho - first one on IDS_APP_TITLE. Thought it was lack of Gdi32.lib, but found out its added in linker by default.
Ill try toying with this a bit more, but Visual Studio is black magic to me >_> So far Ive worked with C applications,hardware stuff (LabWindows, LabView) and FPGA enviroments - this is so much different :P
Working on finishing [1], should be ready in a couple hours. @RobinHood70 Have you had a look at the GES problems?
Updated
I've done an initial version of the short names in 3ce4083c614a620f88b3c485dbf6b5d23dc79246, have a look, @RobinHood70 .
I've also done other things in the last commits, have a general look if they are decently done.
Hey, I've been down with the flu for the last week, but I'll have a look at it today.
That works!
I'm working on finishing the help, if you can finish the GES part, @RobinHood70 , we'll release today/tomorrow.
@12345ieee's edit: some replies were deleted, this is an issue better documented in #22
i just fudged some code to switch focus on the game window which was temperamental but worked to a fashion, But noticed when i ran under administrator to remove the config save errors due admin rights the game focus error i was having didn't occur.
System.Configuration.ConfigurationErrorsException: Failed to save settings: An error occurred loading a configuration file: Access to the path 'C:\Users\dave\AppData\Local\gemforce-team\WGemCombiner.exe_Url_qtaijugc4nwgcbsgcfz2b5ybfvowgc0q\1.1.0.0\sqvvlxh5.tmp' is denied. (C:\Users\dave\AppData\Local\gemforce-team\WGemCombiner.exe_Url_qtaijugc4nwgcbsgcfz2b5ybfvowgc0q\1.1.0.0\user.config) ---> System.Configuration.ConfigurationErrorsException: An error occurred loading a configuration file: Access to the path 'C:\Users\dave\AppData\Local\gemforce-team\WGemCombiner.exe_Url_qtaijugc4nwgcbsgcfz2b5ybfvowgc0q\1.1.0.0\sqvvlxh5.tmp' is denied. (C:\Users\dave\AppData\Local\gemforce-team\WGemCombiner.exe_Url_qtaijugc4nwgcbsgcfz2b5ybfvowgc0q\1.1.0.0\user.config) ---> System.UnauthorizedAccessException: Access to the path 'C:\Users\dave\AppData\Local\gemforce-team\WGemCombiner.exe_Url_qtaijugc4nwgcbsgcfz2b5ybfvowgc0q\1.1.0.0\sqvvlxh5.tmp' is denied. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access) at System.CodeDom.Compiler.TempFileCollection.EnsureTempNameCreated() at System.CodeDom.Compiler.TempFileCollection.AddExtension(String fileExtension, Boolean keepFile) at System.Configuration.Internal.WriteFileContext..ctor(String filename, String templateFilename) at System.Configuration.Internal.InternalConfigHost.StaticOpenStreamForWrite(String streamName, String templateStreamName, Object& writeContext, Boolean assertPermissions) at System.Configuration.ClientSettingsStore.ClientSettingsConfigurationHost.OpenStreamForWrite(String streamName, String templateStreamName, Object& writeContext) at System.Configuration.MgmtConfigurationRecord.SaveAs(String filename, ConfigurationSaveMode saveMode, Boolean forceUpdateAll) --- End of inner exception stack trace --- at System.Configuration.MgmtConfigurationRecord.SaveAs(String filename, ConfigurationSaveMode saveMode, Boolean forceUpdateAll) at System.Configuration.ClientSettingsStore.WriteSettings(String sectionName, Boolean isRoaming, IDictionary newSettings) --- End of inner exception stack trace --- at System.Configuration.ClientSettingsStore.WriteSettings(String sectionName, Boolean isRoaming, IDictionary newSettings) at System.Configuration.LocalFileSettingsProvider.SetPropertyValues(SettingsContext context, SettingsPropertyValueCollection values) at System.Configuration.SettingsBase.SaveCore() at System.Configuration.SettingsBase.Save() at WGemCombiner.GemCombiner.GemCombiner_FormClosing(Object sender, FormClosingEventArgs e) at System.Windows.Forms.Form.WmClose(Message& m) at System.Windows.Forms.Form.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Interesting. We're just using the built-in .NET configuration settings. I'm surprised that they would react that way, but this is my first time using them, so now I know that they do. I'll do some research on the issue, but I don't know if there'll be an easy fix other than to not install the program to Program Files (or similar admin-only folder).
I just tested on my machine and had no problems with it. As ieee suggested, can you please start a new issue on this and include your OS and where you installed the app to. Thanks!
99 out of 100 there are some problems in the folders of the user 'dave' who can't access his own appdata folder.
Robin, we have no installer, the exe can be kept wherever you want. Il 05/gen/2016 17:27, "Robert Morley" notifications@github.com ha scritto:
Interesting. We're just using the built-in .NET configuration settings. I'm surprised that they would react that way, but this is my first time using them, so now I know that they do. I'll do some research on the issue, but I don't know if there'll be an easy fix other than to not install the program to Program Files (or similar admin-only folder).
— Reply to this email directly or view it on GitHub https://github.com/gemforce-team/wGemCombiner/issues/21#issuecomment-169050678 .
ieee: I know that. :) I assumed he'd copied it to Program Files, and that that was why there was a permissions error. I'm inclined to agree that the permissions error is probably in his user folder rather than where he installed the .exe.
@RobinHood70 Do you plan on modifying something? I plan on releasing v1.1.1 tomorrow, with just the changes that are in now plus a mention of the "Run as admin bug" in some places.
No, I won't be changing anything. I looked into the problems with admin rights being required in some situations, and that's normal for programs that inject mouse movements or key presses into other programs. It doesn't happen in all situations and depends on a lot of things. The only way we can work around it would be to provide a full installer with a digital certification included that allows us to request admin privileges programmatically. It's probably easier to just mention that you may need to run the program as an administrator.
@RobinHood70 Somehow a bit unrelated, do VS have a fancy way of building a simple distributable package that has the exe, the recipes.txt and LICENSE & README? Because running the linux shell script after copying the files around is not exactly practical, beautiful of maintainable in the slightest.
Googling quickly, it looks like VS considers a setup package to be just another type of project that you can create. I've never done that before, though, and I have other things that I need to look at in the next week or two, so it might be a while before I can look into this more deeply.
@12345ieee @RobinHood70 When creating non-dependency binaries, I find that simply writing out the files at startup, when they don't already exist, just 'works' for everybody. Then run UPX on your application's .exe to cut the size way down instead of creating an installer. If you go the VS Setup route, it's not just a lot more work and another project, but you're leaving footprints on everybody's machine that you may not have intended. Multiple registry changes, directories, shortcuts, and a requirement to uninstall.
I have a feature request When the "Combine" button is pressed a hint the press '9' is displayed. '9' should only work in this mode, and when 9 has been used and completed, the button should return to 'Combine', and need to be pressed again to make the '9' hotkey live. I can't tell you how many times I press 9 while tabbed out of the game to have my mouse and keystrokes start running away from me before I realized what's happening, hold ESC, tab to the program to close it (apparently the only way to stop it from triggering on '9', changing recipes doesn't even work), then go back to where I was and press Control-Z repeated to undo the fun :)
It actually happens enough that I've just gotten use to closing Gem Combiner after each use, and then reopening it when I'm ready to combine gems to higher grades.
For wGC 1.1 release
*
at the end of the slots number, to mark combines that had needed to be condensed (done: ebdf6a1fe990c4c70da65c4b9eb38ace9243858c)Consider for Future Versions