Grid Sage Forums
- May 06, 2024, 02:53:30 AM
- Welcome, Guest
|
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2476
Fixed Bugs & Non-Bugs / Re: Volley accuracy
« on: October 04, 2016, 06:37:28 PM »1st shot in a volley immobilized the enemy, the 2nd shot then got increased accuracy. But all shots in a volley are supposedly shot at the same time, right? Is this desired behavior?The accuracy of every shot, even each projectile for a multi-projectile weapon, is calculated separately, and technically not until you see it fire, so yes this is normal. This keeps the situation (both this and other factors) more in line with what you see.
Edit: Also, if one of your weapons jams, the recoil penalty is applied to weapons before it but not in weapons after it.True! This is because all weapons are fired in sequence but it's not until a given weapon is about to fire that it determines whether it fails or not due to system corruption. I could change it so that the chances are predetermined for consistency. (Corruption failure was a new mechanic tacked on to the process later...)
2477
Competitions / Re: High Scores
« on: October 04, 2016, 06:21:13 PM »
Sure! I'll add them to the batch. (You're doing pretty awesome already, it would seem 
)
)
2478
General & Off-Topic / Re: Introduce Yourself!
« on: October 04, 2016, 07:27:10 AM »
Hi Alpha16! Your name strikes a timely chord because there's a robot coming in next week's release named Alpha 7 
Thanks for being a part of making Cogmind's growth and success possible!
Interesting that your intro to roguelikes was DF. It certainly has a pretty broad exposure, but a lot of newer folk bounce off the complexity and ASCIIness of it, too (as an intro, anyway). You'll find Cogmind was built for ASCII from the ground up (but still three quarters of players mostly stick to the tileset xD).
Thanks for being a part of making Cogmind's growth and success possible!
Interesting that your intro to roguelikes was DF. It certainly has a pretty broad exposure, but a lot of newer folk bounce off the complexity and ASCIIness of it, too (as an intro, anyway). You'll find Cogmind was built for ASCII from the ground up (but still three quarters of players mostly stick to the tileset xD).
2479
Support / Re: Cogmind on a 4K monitor
« on: October 04, 2016, 02:12:34 AM »
I was just investigating this issue for the Alpha 11 release, and solved it
The separate DPI scaling issue aside, I found an assumption deep in the resolution code that had assumed a maximum of 1440p, even though I had later added support for 2160p fonts. That's why you were being capped at size 24 until you manually edited the cfg, which skips the font guessing phase of startup. Come next week it will work automatically! Thanks for the help.
The separate DPI scaling issue aside, I found an assumption deep in the resolution code that had assumed a maximum of 1440p, even though I had later added support for 2160p fonts. That's why you were being capped at size 24 until you manually edited the cfg, which skips the font guessing phase of startup. Come next week it will work automatically! Thanks for the help.
2480
Fixed Bugs & Non-Bugs / Re: Scrolling the list of analyzed parts doesn't work right.
« on: October 03, 2016, 05:44:38 PM »
Wow that's a lot of parts! Pretty sure it's rare for anyone to have done that much scanning--no wonder no one else has reported this 
It only happens when opening and immediately scrolling down to click on something not among the first 26 items, but not if you first click on something within the top 26 before scrolling, in which case it will work normally throughout. So that's a temporary workaround until the next release, which includes a fix. Thanks!
Edit: Looking into it now and also discovered it doesn't occur when using the keyboard shortcuts.
Edit 2: The plot thickens. You can still use the right mouse button to get the right info as expected. It's only the left mouse button that causes this problem, because the list window isn't normally used in the way it is for schematics, which allows info to be pulled up with either button.
It only happens when opening and immediately scrolling down to click on something not among the first 26 items, but not if you first click on something within the top 26 before scrolling, in which case it will work normally throughout. So that's a temporary workaround until the next release, which includes a fix. Thanks!
Edit: Looking into it now and also discovered it doesn't occur when using the keyboard shortcuts.
Edit 2: The plot thickens. You can still use the right mouse button to get the right info as expected. It's only the left mouse button that causes this problem, because the list window isn't normally used in the way it is for schematics, which allows info to be pulled up with either button.
2481
Fixed Bugs & Non-Bugs / Re: Melee analysis suite bonus.
« on: October 02, 2016, 10:54:58 PM »
Urg, and that's another reason I hate using floats xD
Accuracy started out with float-based calculations many years ago and I simply kept using that same system, despite it becoming increasingly complex with lots of new components. Most of those new components are integer-based (as per my normal tendency towards "super simple math"), and several times now I've forgotten to convert a new feature. That one's been in there forever, though! Probably because they are underused... Okay, no more freebie modified melee attacks! 5 was supposed to be 0.05. Thanks and fixed.
Regarding the cap, it's actually set at 95%, but because it's handled as a decimal the final value might come out to be something like 0.949999. All display values are integers, however, which are simply truncated rather than rounded. (The manual makes mention of this.) In practice it's more accurate than that, because a decimal value is used for your hit attempt.
Accuracy started out with float-based calculations many years ago and I simply kept using that same system, despite it becoming increasingly complex with lots of new components. Most of those new components are integer-based (as per my normal tendency towards "super simple math"
), and several times now I've forgotten to convert a new feature. That one's been in there forever, though! Probably because they are underused... Okay, no more freebie modified melee attacks! 5 was supposed to be 0.05. Thanks and fixed.Regarding the cap, it's actually set at 95%, but because it's handled as a decimal the final value might come out to be something like 0.949999. All display values are integers, however, which are simply truncated rather than rounded. (The manual makes mention of this.) In practice it's more accurate than that, because a decimal value is used for your hit attempt.
2482
Everything REXPaint / Re: Show off your REXPAINT creations
« on: October 02, 2016, 05:32:05 PM »
Ooh yeah that looks great.
2483
Competitions / Re: Weekly Seed #59 [Alpha 10] [Seed: Sudden Death]
« on: October 02, 2016, 08:08:41 AM »Spoiler (click to show/hide)
2484
Fixed Bugs & Non-Bugs / Re: Bullet path
« on: September 29, 2016, 07:29:44 PM »
It's the same cause as the other circumstances we talked about. Due to the angle of fire you're still likely to miss because it's barely grazing the corner. The color predicting whether or not you have line of fire can't be sure of that (since it's still possible to hit, just less likely than your actual accuracy). Sentries are large but still don't fill their entire cell like Behemoths do (but they still take up more space than Grunts, and much more than Swarmers).
2485
Fixed Bugs & Non-Bugs / Re: Scanning unidentified prototypes
« on: September 29, 2016, 07:22:22 PM »
And there it is
2486
Fixed Bugs & Non-Bugs / Re: Scanning unidentified prototypes
« on: September 29, 2016, 06:54:42 PM »
Ooh, good catch. I think the better solution here would be to turn this into a feature: Inserting any prototype into a Scanalyzer now automatically identifies it for you
2487
Ideas / Re: Storage Unit Rebalancing
« on: September 29, 2016, 08:38:24 AM »
One thing to remember: Not all parts are intended to be perfectly balanced for the player. They are for other robots, too.
And don't underestimate Lgt. Storage until you're running flight builds
. A 4-mass gap can be pretty significant.
And don't underestimate Lgt. Storage until you're running flight builds
. A 4-mass gap can be pretty significant.
2488
Fixed Bugs & Non-Bugs / Re: Defensive analysis bonus
« on: September 28, 2016, 08:10:30 AM »
Ah right yeah, covered that you get a +5 and therefore have the analysis... oops, getting really sleepy here after a long day! -_-
2489
Ideas / Re: Utility to Reduce Swap/Attach time unit
« on: September 28, 2016, 07:45:25 AM »
Utilities are generally designed to provide a single benefit, and scale that benefit so that it is worthwhile for the slot(s) it requires. This makes comparison of items somewhat easier, which is important in a game with so much inventory management and item swapping.
Combined effects aren't impossible, and certainly some items are less worthwhile than others in almost all cases (since they might be intended more for other robots rather than yourself), but I try to stick to that theme in the design. We'll see!
Combined effects aren't impossible, and certainly some items are less worthwhile than others in almost all cases (since they might be intended more for other robots rather than yourself), but I try to stick to that theme in the design. We'll see!
2490
Fixed Bugs & Non-Bugs / Re: Defensive analysis bonus
« on: September 28, 2016, 07:42:05 AM »
Heh, an analysis of you... Well, there is one area of the game where something along those lines has an impact 
(no one has seen it yet--coming in Alpha 11)
I wouldn't completely rule out that there was a problem somewhere, but I see the code (and in action) and it's applied every time, so I'm tending to believe something else might've been the case. Though yeah there didn't seem to be heat at play--maybe movement? Maybe you didn't actually have the analysis for that particular variant? Keep an eye on it and we'll see.
(no one has seen it yet--coming in Alpha 11)I wouldn't completely rule out that there was a problem somewhere, but I see the code (and in action) and it's applied every time, so I'm tending to believe something else might've been the case. Though yeah there didn't seem to be heat at play--maybe movement? Maybe you didn't actually have the analysis for that particular variant? Keep an eye on it and we'll see.
2491
Fixed Bugs & Non-Bugs / Re: Defensive analysis bonus
« on: September 28, 2016, 12:17:30 AM »
It appears to be working normally, yes. Maybe there's some other value you haven't taken into account there, considering how many there are that feed into accuracy xD. It would help identify which they are if the calc window showed their hit% breakdown in addition to yours, but I left that out of even the FULL detail level to cut down on clutter. I just tested it by allowing it to show enemy hit calculation as well, the second shot occurring after gaining the analysis:
It's true this shot appears to be the same situation and is at 80%, but I don't know what other conditions were present at the time of your screenshot.
It's true this shot appears to be the same situation and is at 80%, but I don't know what other conditions were present at the time of your screenshot.
2492
Everything REXPaint / Re: Show off your REXPAINT creations
« on: September 26, 2016, 07:47:23 PM »
Hey melrabo! Wrong link? I don't see it here.
2493
Fixed Bugs & Non-Bugs / Re: Combat log hit location
« on: September 26, 2016, 06:25:00 PM »
It turns out there are a bunch of reasons the hit location won't show. While not applicable here, no location will be listed if resistances prevented all damage, or the damage couldn't be applied for any of a number of reasons (usually special weapons/mechanics), or the robot was destroyed by an earlier weapon in the same volley. Of course there's also the lack of a listing during part destruction because that's in the log (the intention there was to keep duplicate data out of the calculation log, since it's rather small and scrolls fast).
It also won't show if the shot was accurate but didn't connect; in other words the target is behind something else like a robot, wall, or machine so the projectile didn't actually reach it. Technically the "hit" is recorded immediately on firing rather than on projectile impact, which was a compromise to ensure complete object data was available for the log since any number events could destroy reference objects once the projectile is in motion. (I.e., internally it was less complicated to do this way, and it was done back when the game was much simpler)
None of the above conditions really apply to what we're looking at here, so I poked around for over an hour and found the source. Turns out it is a side effect of the dislocated hit + location messaging system. This is because even when you succeed at the accuracy check (and therefore get the "HIT" text), when firing at a small target (e.g. Swarmers, Watchers), the projectile still might pass through their location without hitting them because they have such a small profile (in Cogmind robots actually take up an area of 2D space within their cell based on their profile). You can test this by lining up along an axis and firing at a tiny/small robot, where you can clearly see if/when the projectile appears to shoot straight through it--consider this passing above/below the robot.
I'll take that into consideration when revamping the calc log and see if those can be counted as misses as well.
It also won't show if the shot was accurate but didn't connect; in other words the target is behind something else like a robot, wall, or machine so the projectile didn't actually reach it. Technically the "hit" is recorded immediately on firing rather than on projectile impact, which was a compromise to ensure complete object data was available for the log since any number events could destroy reference objects once the projectile is in motion. (I.e., internally it was less complicated to do this way, and it was done back when the game was much simpler
)None of the above conditions really apply to what we're looking at here, so I poked around for over an hour and found the source
. Turns out it is a side effect of the dislocated hit + location messaging system. This is because even when you succeed at the accuracy check (and therefore get the "HIT" text), when firing at a small target (e.g. Swarmers, Watchers), the projectile still might pass through their location without hitting them because they have such a small profile (in Cogmind robots actually take up an area of 2D space within their cell based on their profile). You can test this by lining up along an axis and firing at a tiny/small robot, where you can clearly see if/when the projectile appears to shoot straight through it--consider this passing above/below the robot.I'll take that into consideration when revamping the calc log and see if those can be counted as misses as well.
2494
Support / Re: Weirdness with mouse
« on: September 26, 2016, 05:12:55 PM »
Heh, well, I sorta know what you were referring to, since I've seen it happen before, but I just wanted to hear your take on it before saying anything more.
It's not too common, only happens/matters when you have the cursor off, and the fix is generally to move the cursor around and get it back in the map area. Really everything should work okay if you're hiding the cursor and keep your trackpad disabled to avoid having the cursor shifted accidentally. I've only ever seen it happen when playing in keyboard mode while multitasking in and out of the window for development purposes, not during regular play.
If you can figure out some steps to reliably produce it I might be able to find a fix, but it's pretty minor.
It's not too common, only happens/matters when you have the cursor off, and the fix is generally to move the cursor around and get it back in the map area. Really everything should work okay if you're hiding the cursor and keep your trackpad disabled to avoid having the cursor shifted accidentally. I've only ever seen it happen when playing in keyboard mode while multitasking in and out of the window for development purposes, not during regular play.
If you can figure out some steps to reliably produce it I might be able to find a fix, but it's pretty minor.
2495
Fixed Bugs & Non-Bugs / Re: Volley analysis readout
« on: September 26, 2016, 09:01:09 AM »
Hm, I don't see anything wrong here, because a Lgt. Assault Rifle has a longer range than the Med. Laser. When you move outside the range of the Med. Laser, it's the Lgt. Assault Rifle which will fire, hence the laser is no longer highlighted in the volley list, and all the costs are that of the rifle itself, including time, matter, and energy.
2496
Fixed Bugs & Non-Bugs / Re: Combat log hit location
« on: September 26, 2016, 08:48:50 AM »Sometimes combat log doesn't report what part of the robot you hit. If you destroy the part it doesn't show in the combat log, but it does show in the regular log. But sometimes in other cases it also isn't reported.The combat log was only added (by request back during the 7DRL) to provide additional information that isn't in the regular log, which is why you won't see part destruction messages. Not sure what you mean isn't being reported where, but I'm sure there's an explanation (i.e. it's intentional) since it's very simple code without any kinds of special exceptions. The whole combat log needs to be worked, though, actually (or at least reassessed), but I haven't gotten to that yet since I've always seen it as pretty low priority.
It's been discussed a couple times on the forums, but that was last year and I see it at literally the very bottom of my long TODO list
. I'll move it up higher and see about fixing it up over the next couple releases if no other pressing UI features get in the way.Also if you have full info, the probability of hitting the part you hit is shown, even if you don't have scan enhancer that would show you robot parts and chance to hit them, but that might be intended.Yeah that's intended.
2497
Support / Re: Weirdness with mouse
« on: September 25, 2016, 10:55:52 PM »
Right, so the first with the wrists can be solved by deactivating the trackpad (I have this problem, too depending on what I'm doing, so I just use a hotkey).
Assuming you disable your trackpad so that the first is no longer an issue, what causes the second--you mean when you intentionally put the cursor outside the game window? (Just confirming and then I can provide more info.)
Assuming you disable your trackpad so that the first is no longer an issue, what causes the second--you mean when you intentionally put the cursor outside the game window? (Just confirming and then I can provide more info.)
2498
Support / Re: Weirdness with mouse
« on: September 25, 2016, 10:45:56 PM »
I thought the original problem was what you mentioned at the opening, that bumping your laptop moves the cursor due to the trackpad. Disabling the trackpad will prevent that behavior.
Did I misunderstand? Maybe I'm no longer sure what problem is trying to be solved here.
Did I misunderstand? Maybe I'm no longer sure what problem is trying to be solved here.
2499
Support / Re: Weirdness with mouse
« on: September 25, 2016, 10:06:53 PM »
It's true the cursor is only hidden and not completely disabled, in order to keep behavior identical between the two modes in the simplest way possible. It's unrelated to the OS--this is standard Cogmind UI behavior.
My advice here is to use your laptop's hotkey to temporarily deactivate the trackpad (I tend to keep mine disabled when using lots of different software for that same reason). For example on my ASUS it's Fn+F9. Not sure what the equivalent would be on your Linux machine.
My advice here is to use your laptop's hotkey to temporarily deactivate the trackpad (I tend to keep mine disabled when using lots of different software for that same reason
). For example on my ASUS it's Fn+F9. Not sure what the equivalent would be on your Linux machine.
2500
Fixed Bugs & Non-Bugs / Re: Inconsistent broken robot interaction
« on: September 25, 2016, 07:49:47 PM »
Okay, I've fixed these without changing the overall behavior. What was really needed was to make sure that prefab-placed broken robots were not assigned to an allied faction. I'd assigned them factions based on their origin, but that doesn't make sense in some cases you run across in the caves since they're permanently broken anyway (and yes, meant for you to scavenge parts from ).
).