Is this map cursed?

[planetfall]

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 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?

[Gameboytm101]

Well, I didn't experience the flickering on resourcepacks or creeper, but I did experience it on the command node.


EDIT: I tested some more, and I did in fact experience texture flickering on creeper, as well as some of your UI elements.

[planetfall]

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?

[Gameboytm101]

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...

[Builder17]

Maybe getting error log after playing that map could show something?  :-\

Error log finding instructions: https://knucklecracker.com/forums/index.php?topic=16476.0

[planetfall]

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.

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

Code Select Expand


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...

[Builder17]

I got this error many times:

Code Select Expand

HandleD3DDeviceLost
  HandleD3DDeviceLost: still lost
Skipped frame because GfxDevice is in invalid state (device lost)
(Filename:  Line: 1408) 

And had this once:

Code Select Expand

HandleD3DDeviceLost
  HandleD3DDeviceLost: needs reset, doing it
FullResetD3DDevice
ResetD3DDevice
dev->Reset
D3Dwindow device not lost anymore

But nothing really odd in these , I guess.  :-\

[Gameboytm101]

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.

[planetfall]

There was a problem in CelResBar.crpl. I fixed that but the graphics problems continue for me... see if you have them as well.

[GoodMorning]

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.

[planetfall]

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.

[GoodMorning]

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.

[planetfall]

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 &amp. 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.

[GoodMorning]

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.

[planetfall]

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...