Hey all. Here's a map I've been working on... currently it's very hard (likely impossible) but balance is not what I'm asking about today.
When I play this map I sometimes get texture flickering on resourcepacks as well as, rarely, soylent and creeper/AC. One of the things that seems to cause it is hovering the collector build cursor over an elevation change, though this doesn't always cause it. Since that involves purely vanilla stuff I decided to test it on Ormos, to ensure it isn't a driver or hardware problem. (It still may be, but I didn't get any problems on Ormos.) Since there have been instances where a script screwed with normal behavior, I've scoured the scripts for something like a potential divide-by-zero error, but no dice. (again, entirely possible that I missed something.) I also have another map with the same scripts where this problem does not occur. I also gave Arca and Turkos Prime a quick go, to confirm that it's not a "too many scripts" thing. It wasn't, they work flawlessly (and both were harder than I remember ;))
I think this isn't quite the same as this problem (http://knucklecracker.com/forums/index.php?topic=20846.0) as it occurs in both 2.12 and 2.08 and I've done a system update earlier today.
Also maybe related (or not), the MessageArtifact.crpl (under the sprayer tech) works fine in Finalized maps but only about 2/3 of the time in edit mode.
Any clue what's going wrong here?
Well, I didn't experience the flickering on resourcepacks or creeper, but I did experience it on the command node.
(http://i.imgur.com/A1s3a7W.png)
EDIT: I tested some more, and I did in fact experience texture flickering on creeper, as well as some of your UI elements.
Quote from: Gameboytm101 on June 21, 2016, 04:28:17 PM
Well, I didn't experience the flickering on resourcepacks or creeper, but I did experience it on the command node.
(image)
EDIT: As well as some of your UI elements.
That's part of the issue I had before, and one I haven't had since updating. Here's something to try - try interacting with the custom build tabs, maybe placing a couple build ghosts, and then returning to the default UI a few times. Do you get to a state where the control panel is invisible, but hovering over the buttons makes them visible again? Or where a bunch of (vanilla) unit buttons are bunched up and half-offscreen? That's another one that hasn't happened since the update. The black command node and the UI glitch do seem to be driver related...
edit: how much scripting knowledge to you have? I know it's a lot to ask, but could you sanity check the scripts for me?
I did further experiementation and it seems like the texture flickering and other bugginess just stops once you've got some sort of foothold. I'm not sure if it was capturing the white holes or something else...
Maybe getting error log after playing that map could show something? :-\
Error log finding instructions: https://knucklecracker.com/forums/index.php?topic=16476.0
Quote from: Gameboytm101 on June 21, 2016, 04:56:11 PM
I did further experiementation and it seems like the texture flickering and other bugginess just stops once you've got some sort of foothold. I'm not sure if it was capturing the white holes or something else...
Hmm...
I did detect a bug that would cause odd behavior after the white holes were captured (adding essence even if the celestial core isn't built). And the solution to this bug resided in Master.crpl not WhiteHole.crpl. But that's the only other script that WhiteHole.crpl gets or sets variables from. Fixing that problem seems to have reduced the graphics problems but that may be my imagination.
Quote from: Builder17 on June 21, 2016, 05:02:35 PM
Maybe getting error log after playing that map could show something? :-\
Error log finding instructions: https://knucklecracker.com/forums/index.php?topic=16476.0
That was the first place I checked. There are a bunch of messages that look like this
Unloading 0 unused Assets to reduce memory usage. Loaded Objects now: 2203.
Total: 19.801001 ms (FindLiveObjects: 0.218000 ms CreateObjectMapping: 0.047000 ms MarkObjects: 19.520000 ms DeleteObjects: 0.014000 ms)
but no exceptions. Those messages appear all the time during normal play so I doubt they'll be much help.
...and now, restarting the game to get a fresh error log from only that mission, it seems that the only time flickering occurred was when the sprayer was picked up. I found another bug in ConvoMenu.crpl which dispensed with that specific flicker. Now I'm just getting one when a command node lands. Here's the marginally updated map and the log.
edit: after I say that the flickering comes back full force. Of course...
I got this error many times: HandleD3DDeviceLost
HandleD3DDeviceLost: still lost
Skipped frame because GfxDevice is in invalid state (device lost)
(Filename: Line: 1408)
And had this once: HandleD3DDeviceLost
HandleD3DDeviceLost: needs reset, doing it
FullResetD3DDevice
ResetD3DDevice
dev->Reset
D3Dwindow device not lost anymore
But nothing really odd in these , I guess. :-\
Once the Celestial Core was constructed, all the graphical weirdness seemed to stop. I unfortunately can't provide much more information, my knowledge on CRPL is limited to snippets of code from various sources.
There was a problem in CelResBar.crpl. I fixed that but the graphics problems continue for me... see if you have them as well.
Before examining the scripts, I tested a bit.
The first symptom was connections layering on top of the CN, associated with the cursor sitting over Ore Packs.
When the White Holes reached -100%, the shadows started layering incorrectly.
After a while, your menu's lock icons were flickering too.
I'm looking at the scripts, but have not yet found anything too bad.
I think there might be an issue with Z layering caused by the addition of units, which is causing various objects to obtain the layering information of another unit. Specifically, I think that there's a small fault in the indexing of a nondefault z-layering array, which has the net effect of swapping the z-coords of various objects, usually built at similar times.
After this has gone on for a while, the layering would become unrelated to the units it's applied to.
On what is hopefully an unrelated note, I was about to start on making a menu such as yours myself. May I steal borrow it? Doing so might even help rule out the source of the graphics issues.
Quote from: GoodMorning on June 21, 2016, 07:00:47 PM
On what is hopefully an unrelated note, I was about to start on making a menu such as yours myself. May I steal borrow it? Doing so might even help rule out the source of the graphics issues.
Be my guest! Though I'm fairly sure it the problem isn't related to the menu as I've made a few maps (none uploaded, I want to finish about 10 and then get feedback on them as a series) with it that don't have this problem.
Many thanks. Any specific instructions for use? I can work it out, but it's probably better all around if I ask now.
Not sure if this helps, but the menu has the three commands that normal units use for deactivate/disarm/no resupply. Perhaps these could become four: "Disconnect" "Shutdown" "[Don't] Charge" "[Don't] Use power". That way, we can still pipe packets through (or not), or speed-disable, but we have somewhat finer control of whether to use power and/or draw power. Naturally disconnecting will override all the others.
You'll need the following scripts:
ControlPanel
ControlBuildTabs
BasicControlButton
Master
BuildCounts
UnitControls
MoveShadow (unless none of your custom units are able to move)
BuildingCursor
Interface.crpl (if you're going to do something of this complexity an interface script is a must anyway.)
TechCache (optional, pickup to increase build limit)
UnlockBuildMenu (optional if you want the build menu to remain hidden. I only used this in the 1st map and had it unlock after picking up the first tech cache)
ConvoMenu (optional, creates that "archive" menu that stores all conversations not just the first)
MessageArtifact (optional, for use with ConvoMenu)
DeathMessage (optional, for use with ConvoMenu)
You'll want core UID 0 to be the master. To ensure that a core has UID 0, quit the game entirely, relaunch, create a new map and create a core before you do anything else. Put Master.crpl and BuildCounts.crpl on this core. Alternately you can change the scripts to use some other UID but that's more work.
Every core should have the Interface script. The corename should be set to the main script of the core minus the .crpl. I also recommend setting the class to something else for UI elements so if you create an AoE weapon it has an easy way to tell "game object" from "UI element"
Create a core with the ControlPanel script. It'll sit there and spawn all the requisite buttons. If you add more types of controls, use BasicControlButton and BuildButton as a model and have ControlPanel spawn them. Also make them die on recompile. This is because you can't delete stuff behind the edit menu, so to delete them just remove the part that makes ControlPanel spawn them.
Create a core with the ControlBuildTabs script, this is your four build tab buttons. If you want the tabs to be something other than Structure/Weapon/Science/Advanced, that's set in the :SetScreen function.
In BuildButton, decide on a short name for each unit. This should be one word or CamelCase, you'll see why later. It should be short enough to fit on the button. This information is found in the :awake function, it should be fairly obvious from the many placeholders how to assign units to a particular tab.
If any units are not 3x3 you'll have to manually add them to BuildingCursor under :SetUnitVars. FootprintSize of 1 means 3x3, 0 means 1x1, 2 means 5x5 etc. Negative values will allow free placement. Even numbered unit sizes, or unequal height and width, are not supported and you'll have to tinker a bit if you want those.
BuildCounts is where lots of information goes. Variable names are based on the short unit name you decided in BuildButton.
$UnitName: The number you can build of that unit, -1 = infinite.
$UnitNameCost: Build cost of the unit. There's currently a stub for units to cost Technytes instead of packets, but that's NYI. Don't preface any build costs with T and you can just leave it in (it's spread across a few scripts anyways.)
The following are set in the :awake function, to keep the script's input var panel tidy since they likely won't change from map to map.
UnitNameTip: The info box that appears above the build panel when you mouse over a unit. The BuildButton script will concat this with information about the build cost.
UnitNameScript: The unit will have this as its corename in interface.crpl, and will have this.crpl added to it by BuildingCursor
UnitNameImg: The image to be used by this unit's build button and BuildingCursor
UnitNameRange: The range of the unit as displayed by BuildingCursor
UnitNamePZRange: The range of the unit on a powerzone as displayed by BuildingCursor
Note that these do not set the actual unit's range or the displayed range of a moving unit by UnitControls... those must be manually set by the unit's script. The range stuff is all kind of kludgey because I want to add upgrades, including range upgrades, and that'll require significant infrastructure that just isn't in place yet.
Store targetability information in the master to reduce expensive GetCoresWithVar calls. (see: StasisProjector, SlipEmitter) Also use it to store global variables multiple scripts may need to access (see: WhiteHole, CelestialCore, the CRe____ scripts). Use CReactor, CelestialCore and StasisProjector as models for how to build units within this system. UnitControls is complicated but all the variables are named for what they do.
For TechCache: set RewardType to UnitLimit, Param to the short name of the unit, and amt to the extra number (again, -1 = infinity). When collected it will show the unit's tip from BuildCounts in a dialog box. (BuildCounts should probably be called UnitData, but so many scripts use it now it'll be painful to change. It's like how my last map series had interface.crpl with an infuriating lowercase i.)
For the optional conversationy stuff:
Create a core with ConvoMenu. You can set the intro in the format char:text;char:text;char:text. To have an actual colon, semicolon, octothorpe or ampersand in the text, use &colon &semi &hash &. Char is a number 0-7 as in SetConversationMessage.
For DeathMessage and MessageArtifact, do the same thing but preface it with Name#. Name will be how the conversation is listed in the menu. Note that ConvoMenu will only display and store the first conversation of a given name, subsequent ones with the same name will be discarded even if the content is different. I recommend you put a DeathMessage on the first of every new tech you introduce, to give whatever lore and usage tips you may have.
From the number of tiles you have on these panels, it looks like the series will be a long one. :)
I would suggest changing one of the tabs to be the equivalent of "Titans", and use fewer, larger tiles.
Much thought has clearly gone into this. I will consider it carefully.
Note: The number of unit types you have suggests that you might end up with a parallel economy, or even two. You mentioned Technyte-based units, and have already defined one custom resource. I'm hoping for the return of the Constructor and it's subsidiary units.
Quote from: GoodMorning on June 21, 2016, 09:45:26 PM
From the number of tiles you have on these panels, it looks like the series will be a long one. :)
I would suggest changing one of the tabs to be the equivalent of "Titans", and use fewer, larger tiles.
Much thought has clearly gone into this. I will consider it carefully.
Note: The number of unit types you have suggests that you might end up with a parallel economy, or even two. You mentioned Technyte-based units, and have already defined one custom resource. I'm hoping for the return of the Constructor and it's subsidiary units.
Some units will return, some will not. There will be a unit called the Constructor but it won't be its old fiddly self.
I plan to have 3 new resources. Celestial Essence can be used to make all other resources and will probably be the only way besides crystals to get Aether. It will also be used to power a few special "enhancer" units, such as PZ generators if I decide to re-add them, or a Refueler that teleports ammo to a target unit. Technytes will be made from energy, ore and Celestial Essence and will be used to build most custom units. There may also be weapons that use them as ammo. Data will be produced by a few structures and used to power a hacker unit or buy upgrades.
There will be 3 pseudo-titan units: the Celestial Core, the Lab (upgrade building... number one of two), and some sort of mobile flying ship thing. Upgrades will unlock powerful activated abilities for them in addition to their normal functions. Though with the way I plan upgrades to work, the lines between "unit" and "titan" will start to blur if you want to specialize...
I look forward to this very much. Another new game mode, it seems.
I finally got around to playing the newest version.
In addition to texture flickering prior to the Celestial Core being built, I found out something else.
I managed getting a Slip Emitter to 2/2 stability, but nothing happened. Whether this is:
- Intended
- Not Yet Implemented
- Requires a Locked Unit to make use of
or just
I'm unsure of.
As for the texture flickering issue, have you tried importing scripts from your other maps that don't have this problem?
I think that stability has to go over 100%, then the slip starts losing health.
Perhaps the texturing issue could be fixed by making a new map and reloading the scripts, then rebuilding?
Quote from: Gameboytm101 on June 22, 2016, 09:32:31 PM
I finally got around to playing the newest version.
In addition to texture flickering prior to the Celestial Core being built, I found out something else.
I managed getting a Slip Emitter to 2/2 stability, but nothing happened. Whether this is:
- Intended
- Not Yet Implemented
- Requires a Locked Unit to make use of
or just
I'm unsure of.
As for the texture flickering issue, have you tried importing scripts from your other maps that don't have this problem?
This is map 4 of an unreleased series so this mechanic was explained earlier. You need to have greater stability than the displayed number to actually cause damage. Having equal to that number halves creeper output and prevents it from healing.
The maps in question have the same exact scripts. A bug in CelResBar would cause a divide by zero error if the celestial core was lost or not yet built, which was not a problem in the prior map featuring it because the core is on the map at the start and the mission fails if it gets destroyed.
I have made a discovery! If all ore packs are removed, the problems cease. Same as if all white holes are stabilized or deleted. So something that runs when white holes are unstabilized hates ore packs, or something in vanilla ore pack code hates what's going on in the white holes. And my test map where I make all these scripts, which works fine normally, suddenly gains the same symptoms if you clone ore packs everywhere.
It's a pity because I wanted to try making finite ore a fun thing. *grudgingly adds ore mine tech and makes it cost double out of spite*
This is a really weird bug and since multiple people are experiencing it V should probably take a look at it with his more-information-y dev tools, but I guess cw3 is old, the bug is niche, and the fleet of particles takes priority. Something to look forward to at least!
Well, that narrows it down to a very short list of code pieces. Does the build state of the Celestial Core relate to it?
... can confirm I was utterly wrong as it keeps happening. Deleting the CelResBar core seems to fix it. As does building the celestial core. Which means that the code causing the CelResBar to be invisible when essence capacity is 0 is the issue. And that was the main change from the prior map that worked. So I've made it simply always display and that seems (have not tested a HUGE amount) to fix it. I REALLY want to know what's so offensive to the game engine about this snippet:
<-EssenceCapacity eq0 <-EssenceBonus eq0 and if
Self "main" 0 0 0 0 SetImageColor
Self "bar" 0 0 0 0 SetImageColor
"" SetPopupText
return
else
Self "main" 0 0 0 255 SetImageColor
Self "bar" 255 200 0 255 SetImageColor
endif
Perhaps "bar" is a reserved name for the packs scripts, or "main" is interfering due to a UID issue?
Another issue I had noted is the inability to double-click to select the Stabilisers, which is probably not implemented, but seems intuitive, because we can do so much that works in normal units. Then again, this would probably give you even more headaches about placement validity. However, it would probably be their primary movement command.
Does this mean that the ore mine is out again?
And finally, if stabilising WHs seemed to fix it, could it be between the two?
I've managed to incidentally "curse" a map by setting a unit image badly. The layering didn't break down, but the Creeper became invisible patchily, and other units lost some main images. Even terrain layering acted oddly w.r.t. the editing cursor for units. Reloading the game hasn't helped.
Even a new map breaks as soon as the script runs, and the Core is deleted rapidly. Any ideas? Possibly something breaks when I change the image and immediately delete the Core?
Script attached.
I eventually found that the issue was due to setting two images (using the same image) on a ScreenMode core invisible with SetImageColor - making them invisible with SetImageScale seemed to work without issue. But that isn't at play here...
Here's my guess. You have here:
CurrentCoords 1 RandCoordsInRange @Target
Which, to my understanding, also considers the center cell. Thus, in 20% of cases, the core calculates the pixel distance to be zero, which causes problems when you reach lines like these:
Self CONST_PIXELCOORDX <-CPC_X <-PD_X <-PD div add SetUnitAttribute
Self CONST_PIXELCOORDY <-CPC_Y <-PD_Y <-PD div add SetUnitAttribute
As for the core deleting itself, I did a quick ctrl-f for "health" and "damage," but everything looks fine in that department.
Another possible culprit is the :split function using SetUnitAttribute rather than SetScriptVar.
Whatever it is seems to be killing it in the first few frames, probably the first, as a test didn't show the trace when expected.
This was written some time ago without compiling in between, and fails the first compile attempt by missing quotes. Then it starts breaking the map when it executes.
Never mind, if you located the issue, then this belongs elsewhere.