refactor: change all WAL tags to be non-zero

This seems safer if the default is for pages to be mostly zeroed out.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#640  👈 (View in Graphite)
#638
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Merge activity

Dec 19, 6:43 AM EST: A user started a stack merge that includes this pull request via Graphite.


Allow ubuntu_install_darknet.sh to work in both 18.04 and 16.04

Our internal CI uses ci_cpu for all testing unlike upstream. The move to 18.04 also dropped pip2 support. This requires darknet installations to drop pip2 installations when on 18.04.
Ramana
@tqchen

@tqchen , the CI broke because of an unrelated missing clang-format error .

please rebase to retrigger the ci


tests: benchmarks: sys_kernel: Enable benchmark for slower SoCs

Few SoCs whose clock speed is very less will cause multiple ticks
to occur for 1 sec of sleep. For such a platform we cant run
the loops for over 5000 because the tick handler will get executed.
Thus rendering the test useless for such platforms. By reducing
the number of iterations we get the required benchmark results.
Fixes: GH-7906
Signed-off-by: Adithya Baglody<EMAIL_ADDRESS>

Codecov Report

Merging #9660 into master will increase coverage by 0.13%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #9660      +/-   ##
=========================================
+ Coverage   52.17%   52.3%   +0.13%
=========================================
  Files         212     212
  Lines       25914   25934      +20
  Branches     5583    5589       +6
=========================================
+ Hits        13520   13566      +46
+ Misses      10145   10122      -23
+ Partials     2249    2246       -3

Impacted Files
Coverage Δ

subsys/net/ip/udp.c
55.55% <0%> (-3.54%)
:arrow_down:

subsys/bluetooth/host/hci_core.c
2.56% <0%> (ø)
:arrow_up:

subsys/net/ip/tcp_internal.h
50% <0%> (ø)
:arrow_up:

subsys/net/ip/net_if.c
61.99% <0%> (+0.27%)
:arrow_up:

subsys/net/ip/net_pkt.c
63.55% <0%> (+0.49%)
:arrow_up:

subsys/net/ip/tcp.c
61.03% <0%> (+2.79%)
:arrow_up:

subsys/net/ip/ipv4.c
73.43% <0%> (+3.12%)
:arrow_up:

drivers/net/loopback.c
84% <0%> (+12%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f72c4c5...ad3ccbf. Read the comment docs.

@AdithyaBaglody please CI issues.


Add option to use custom modal mode status bar icon

Thank you very much! I'm using this in my config now :)


update service install for lasair4 repo

Just noticed that the sherlock service was still being installed from the old repo.

Looks good


Slack OAuth2 provider

Slack OAuth2 provider

+1 for getting this merged

Thanks @k4200. I merged your  changes manually.


Touch column resizing not working correctly in onEnd mode

Describe the bug
When using touch screens, the column resizing behaviour does not work correctly when set to 'onEnd' mode.
After debugging this seems to be because the e.touches property is empty when react-table processes the 'touchend' event in this scenario.
It appears from the event API that the touches data will exist in 'e.changedTouches' instead of 'e.touches' once the touch has finished (this also explains why it works in onChange mode, as the values are taken while the touch is still in progress and e.touches is therefore populated)
Tested on a touchscreen laptop using latest of both firefox and chrome and same issue.
(Firefox won't even detect the initial touch start without enabling the legacy touch API setting dom.w3c_touch_events.legacy_apis.enabled, not sure what that is about...)
Code sandbox to reproduce seems unreliable, but is simply the react resize example with the column resize mode altered to 'onEnd'
Your minimal, reproducible example
https://codesandbox.io/s/quirky-estrela-bvzbek?file=/src/main.tsx
Steps to reproduce
Using touch screen, tap and hold resizer on column header, drag to resize then release.
Expected behavior
Column size is updated, as with mouse behaviour.
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform
Windows 11, Chrome latest, firefox latest
react-table version
8.7.0
TypeScript version
4.2.4
Additional context
No response
Terms & Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

I ran into this as well. Thank you for debugging this @cjpmedius. Based on your diagnosis, I am currently running with this workaround that monkey patches TouchEvent to alias touches to changedTouches:
const touchesProperty = Object.getOwnPropertyDescriptor(
  TouchEvent.prototype,
  "touches",
);
Object.defineProperty(TouchEvent.prototype, "touches", {
  ...touchesProperty,
  get() {
    if (this.type === "touchend") {
      return this.changedTouches;
    }
    return touchesProperty.get?.apply(this, []);
  },
});

(use at your own peril.)


NPE when running readBytes with future module

The following ammonite script
import $ivy.`io.iteratee::iteratee-files:0.8.0`

import scala.concurrent.ExecutionContext.Implicits.global

val fileModule = io.iteratee.modules.future
val fileFuture = io.iteratee.files.future

import cats.implicits._
import fileModule._
import fileFuture._

val res = readBytes(new java.io.File("/dev/urandom")).into(takeI(1))
res.onFailure { case t => t.printStackTrace }

prints a following stack trace
java.lang.NullPointerException
        at scala.concurrent.impl.Promise$KeptPromise$Kept.onComplete(Promise.scala:368)
        at scala.concurrent.impl.Promise$KeptPromise$Kept.onComplete$(Promise.scala:367)
        at scala.concurrent.impl.Promise$KeptPromise$Successful.onComplete(Promise.scala:375)
        at scala.concurrent.impl.Promise.transformWith(Promise.scala:36)
        at scala.concurrent.impl.Promise.transformWith$(Promise.scala:34)
        at scala.concurrent.impl.Promise$KeptPromise$Successful.transformWith(Promise.scala:375)
        at scala.concurrent.Future.flatMap(Future.scala:301)
        at scala.concurrent.Future.flatMap$(Future.scala:301)
        at scala.concurrent.impl.Promise$KeptPromise$Successful.flatMap(Promise.scala:375)
        at cats.instances.FutureInstances$$anon$1.flatMap(future.scala:13)
        at cats.instances.FutureInstances$$anon$1.flatMap(future.scala:10)
        at io.iteratee.Enumeratee$$anon$25.apply(Enumeratee.scala:11)
        at io.iteratee.Enumerator.intoStep(Enumerator.scala:15)
        at io.iteratee.Enumerator.$anonfun$into$1(Enumerator.scala:17)
        at scala.concurrent.Future.$anonfun$flatMap$1(Future.scala:302)
        at scala.concurrent.impl.Promise.$anonfun$transformWith$1(Promise.scala:37)
        at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:60)
        at scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:140)
        at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
        at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
        at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
        at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)

I am able to run simple enumerators like iterate(1)(_ + 1) with future module. But all of the file enumerators that I tried fail with NPE when ran with future module.
NPE is from executor.prepare(). Execution context in the future module is null?

Ugh, thanks for the report. I'm taking a look now.

Yep, you're right. I know the future module doesn't get used much but I thought our tests were better than this.

The fix is pretty straightforward (one def-to-val), but I'd like to get tests in place to verify that something like this doesn't happen again, and all other things being equal I'd prefer to wait for Cats 0.9 to publish a new version. Do you need this right away, @2m?

Thanks for fixing this so quickly. I am fine with whenever the new version gets released.


feat: add tags for reasoning and knowledge

I also deleted many questions. I did this when:

questions did not really test chemical knowledge/understanding (and questions could be answered by string matching questions/answer)
the answer options were overall general/lacking nuance
there seemed to be something wrong

I know that this PR does not follow the "minimal possible PR principle" we follow. The reason for deviation is that this PR is mostly a big refactor and not an addition of new content.

the tag “difficulty-...” is missing in some of these questions, did you do this on purpose?
or should it always be included together with the tags “requires-knowledge” or “requires-reasoning”?
if so, I will try to include it in some questions (if I can decide that with my knowledge)

it is still a draft PR as I didn't manage it yet through all files. So far, I  only included the difficulty for "basic" and "advanced" questions but nothing in between

skipping reviews for now to not block re-run.


Unknown flag --moniker while building testnets

Description:

yarn build:testnets outputs the following
yarn run v1.13.0
$ cd tasks/build/testnets && ./localBuild.sh
c55cfd2aa03abf5f91f8cbe65c8dd32945b20254e2eb62c8b4473ef335746207
builder

Copying testnet configuration files...

ERROR: unknown flag: --moniker
sed: can't read /root/.gaiad/config/config.toml: No such file or directory
Cloning into 'builds/testnets'...
cp: cannot stat '/root/.gaiad/config/config.toml': No such file or directory

cc @sabau

Is this the same error as #1362 ?

This probably has to do with a newer Gaia version.

I think this should be already fixed in develop

can we close?


docs: update Kong implementation statuses

What this PR does / why we need it:
/kind documentation
Which issue(s) this PR fixes:
This PR reflects that changes in kong implementations of gateway api.

The Kong support for Gateway API (via Kong Kubernetes Ingress Controller) was moved to beta by https://github.com/Kong/kubernetes-ingress-controller/pull/2781
The Kong Gateway Operator user facing repository was changed to https://github.com/Kong/gateway-operator-docs

Does this PR introduce a user-facing change?:
NONE

@jrsmroz you'll need to sign the CLI, and then
/lgtm


fix EDS race with hc initialization when hc ignored on host removal

Signed-off-by: Michael Puncel<EMAIL_ADDRESS>Commit Message: Fix EDS race with health check initialization causing stuck warming clusters
Additional Description: This commit addresses a race condition that affects clusters with the "ignore_health_on_host_removal option set. If a host is removed from the cluster before health checks are run on it, the cluster manager gets stuck forever. This issue is solved by running health check initialization callbacks when a health check is destroyed in addition to when a health check completes.
Risk Level: Low
Testing: Integration test
Docs Changes: N/A
Release Notes: Included bug fix note
Platform Specific Features: N/A
Fixes #17836

The new test I added in his commit fails due to a RELEASE_ASSERT i'm stumped by here. I got tripped up trying to find where cluster.cluster_0.update_success is incremented, I assumed the callsites in grpc_mux_impl.cc  but didn't seem like it. The assert fails because update_successes_ is 3 while cluster.cluster_0.update_success is 5, could use a pointer. I'll also try again tomorrow.

/retest


Be clear about how unique/persistent service/plan IDs are

ping @vaikas-google - and what is Martin's github id?
Signed-off-by: Doug Davis<EMAIL_ADDRESS>

LGTM

reviews needed

LGTM

lgtm

LGTM


Make the default markdown editor the editor, not the renderer

I'm not sure how to do this, actually. I think it makes sense to make the default renderer for markdown the editor, since likely people will be writing markdown files more than viewing them. However, our defaults system automatically puts things registered for .md files above the global editor default.
Thoughts?

CC @groutr, @blink1073 at least.

I think the default * widget should take precedence over a widget that can open a file of a particular type.

It makes sense to me.  Out of sheer curiosity, is there a mechanism for a user to select a default viewer for a file type, like an "Always open with..." action?

Not yet, that will require persistent settings.

I think the default * widget should take precedence over a widget that can open a file of a particular type.

Makes sense. See #521.


Outdated old version of documentation

The repository still contains the predecessor of "packagedoc": the "doc" folder - with the in between outdated Sphinx based documentation.
When the content is ported to the new folder completely, this "doc" folder should be removed.

Hi Son,
please correct this.
Thank you,
Thomas

already merged with #37


[ios] cocoapods support

Hey, thank you for the great work of keeping this lib fixed and alive, filed a few PRs in original for improvements so far in the past and them are still there... will plan to send here too so we can have them working.
Was wondering if you have any plan of support cocoapods, having a repo to replace the old lib as framework and avoid any manual build and drag and drop.
Basically build with
make xcframework BUILDTYPE=Release

And catch the dynamic result in a pod?

We distribute iOS build as Swift Package, see https://github.com/maplibre/maplibre-gl-native#ios

@petr-pokorny-1 yeah I see, I was thinking if also pods was a viable way to add to a project, just to avoid to mix package with cocopods that I see doesn't work that well so far (made a few quick test and was not working for me so far that combination).
Idea was more to cover older projects that are still using the pod way.

Ok, I see. Unfortunately the team is small currently and we have a lot to do so I dont see the team here could implement cocoapods support anytime soon. PR from the community would be greatly appreciated!

@petr-pokorny-1 here's a starting point https://github.com/matteocrippa/maplibre-cocoapods
Double checked locally and seems to work as a kinda fast replacement for any previous lib.
Now to double check the whole flow it would be great to:

create similar repo under the org of maplibre
using a maplibre account publish the pod file ( https://guides.cocoapods.org/making/making-a-cocoapod.html )

We refer directly to the zip with the release so it will be much easier to manage, also prolly worth considering a bit of scripting to later make this flow automatic.

MapLibre as a Swift Package should work famously with the CocoaPods or Carthage depedency managers.  Please file an issue if MapLibre delivered as SPM fails.  I agree that we should have more demo apps or automated tests that show this.

MapLibre as a Swift Package should work famously with the CocoaPods or Carthage depedency managers. Please file an issue if MapLibre delivered as SPM fails. I agree that we should have more demo apps or automated tests that show this.

I was adding as swift package but I start having issue during the archive, because at the end I had to add the package to the pod too because it was not able to find the Mapbox with import.
The trick above with a dedicated podspec that point to the released should make the life more easy to whom have old project and won't mix pod and swiftlint

I'm not completely sure since I don't have any iOS dev experience, but I think cocoapods support will also be required for #41. AFAIK Flutter plugins can only use cocoapods dependencies.

Mapbox had support for cocoapods indeed, we could try to update and migrate original scripts to MapLibre. See  https://github.com/maplibre/maplibre-gl-native/blob/master/platform/ios/platform/ios/scripts/deploy-to-cocoapods.sh and related. The most work here is to properly integrate cocoapods stuff into automated build process.

@petr-pokorny-1 consider that in the repo I created https://github.com/matteocrippa/maplibre-cocoapods I had to adapt a bit because maplibre zip is different and uses a xcframework.
I was testing it locally using a github reference into the pod and works already.
The missing part is basically:

having it pushed in cocoapods so you can refer into any project like pod Maplibre
tweak the code to update automatically once a new zip version has been released

I just wanted to mention that this might have the benefit of Maplibre being able to be used as a drop-in dependency when using for example Mapbox Navigation, as mentioned in #66.
So if cocoapod support is considered (and navigation isn't forked as well), it might make sense to keep the version and naming intact.

bumping here, I think it is possible to make it work, at least something like this works already:
Pod::Spec.new do |s|
    version = '5.13.0-pre.1'

    s.name = 'MapLibre'
    s.version = version
    s.license = { :type => 'BSD' }
    s.homepage = 'https://github.com/maplibre/'
    s.authors = { 'MapLibre' => '' }
    s.summary = 'Open source vector map solution for iOS with full styling capabilities.'
    s.platform = :ios
    s.source = {
        :http => "https://github.com/maptiler/maplibre-gl-native/releases/download/ios-v#{version.to_s}/Mapbox-#{version.to_s}.zip",
        :flatten => false
    }
    s.ios.deployment_target = '9.0'

    s.ios.vendored_frameworks = "**/Mapbox.xcframework"

    s.dependency "MapboxMobileEvents", "0.10.2"
end

It's more to add an automation that creates that and make a pod trunk push to the repo

@matteocrippa Thanks for introducing the podspec, adding to this, because I've faced a problem and took me sometime to figure out, this problem was with installation, usually i ended up with error like 'No such module found', because the zip wasn't being downloaded first time
to fix this, repo has to be specified as a "Source" not as a "GIT"
so in your podfile, it has to be something like this
 pod 'MapLibre', '5.12.2', :source => 'git@github.com:i0sama/maplibre-cocoapods.git'
I also created a fork of your repo that introduces the podspec, to add folder and version, since 'source' looks for version

Hi @matteocrippa Do you mind adding<EMAIL_ADDRESS>pod trunk add-owner MapLibre<EMAIL_ADDRESS>
Then I can try publishing a new version of the library to Cocoapods.

Done!

@louwers I think we can close this issue, what do you think?

@matteocrippa We can, I will create a separate one for automating the release.

Thanks everybody!


how to build tree with    HashSet ?

i have a  HashSet<>  ,key  is all the  Leaf node  id.  and  i  can get the  pId to.
can i use  this to build a tree ?

Hi @287138531 ,
Thanks for using Scalified Tree Library!
For building the tree, please refer Documentation section Creation

Hi @287138531 ,
Thanks for using Scalified Tree Library!
For building the tree, please refer Documentation section Creation

...the exp is to simple. can get me any tips?

In order to provide you a meaningful help, we need to know the concrete case and troubles you are facing with. Please provide your case: description, sample code, what you are trying to achieve etc.
Also, it would be great if you could clarify what exactly seems to be not covered by Original Documentation.


The __ function is not sprintf compatible.

The conversion script converts code like
 Mage::helper('module')->__("Template file is empty or doesn't exist: %s", $templatePath)

into
__("Template file is empty or doesn't exist: %s", $templatePath);

This is good!  However, the new global gettext style __ is not sprintfcompatible.  It's a numeric based replacment. The above should actually be
__("Template file is empty or doesn't exist: %1", $templatePath);

It would be great if the script could catch and convert these.   If you or the googler who finds this in 6 months is curious , the replacement seems to happen here
vendor/magento/framework/Phrase/Renderer/Placeholder.php

Done


[Mobile][Tablet] the 'Conversation list' panel is closed automatically after deleting a conversation

EPAM AI DIAL chat version
0.14.0
What happened?

Create several conversations
Delete a conversation using the context menu -> the panel is auto-closed -> bug
Delete a conversation using the 'Delete all conversations' button -> the panel is auto-closed -> bug
Delete a conversation using the 'Delete selected conversations' button -> the panel is auto-closed -> bug

Note: the 'Prompt list' panel is NOT closed in these cases (ok)
Note: need to fix for tablet also
Expected result: the 'Conversation list' panel should stay opened so user can see the result
Confidential information

[X] I confirm that do not share any confidential information

on my physical device (iPhone 15 max pro) the Conversation list panel remains opened, but in browser view it is closed. How can it be?


Proposal: Codegen: Return simple objects

Summary
For simple object types where all their fields are non-parametrized scalars, make it more convenient to access the object’s properties in SDKs by returning the whole object at once as a leaf value.
Motivation
Our chainable API is pretty simple, but it also feels limiting when you want multiple related fields, especially if they’re a part of a simple object like EnvVariable, Port or Label.
For example, if I have an EnvVariable object, and I want both the name and value, I need to make two extra requests:
envVars, err := ctr.EnvVariables(ctx)
if err != nil {
    return nil
}
for _, env := range envVars {
    name, err = env.Name(ctx)
    if err != nil {
        return nil
    }
    value, err = env.Value(ctx)
    if err != nil {
        return nil
    }
    fmt.Printf("%s=%s\n", name, value)
}

Same thing with Port, Label and others like these.
This could be much simpler by making a single request that includes all fields in the result:
envVars, err := ctr.EnvVariables(ctx)
if err != nil {
    return nil
}
for _, env := range envVars {
    fmt.Printf("%s=%s\n", env.Name, env.Value)
}

While these are just two fields, Port has three and there’s an issue for adding a FileInfo type (similar to fs.FileInfo) that’ll double that (4 - 6 fields):

https://github.com/dagger/dagger/issues/3457#issuecomment-1397574645
https://github.com/dagger/dagger/issues/3764

Specification
Definition
This proposal defines a “simple object” as:

A GraphQL object type;
Where all fields are leafs that don’t have any arguments;
Doesn’t have an id field (rules out CacheVolume, Socket and Secret).

Codegen
When a simple object is detected, print it the same as an input type (except it should only be used in outputs):
// A simple key value object that represents an environment variable.
type EnvVariable struct {
-	q *querybuilder.Selection
-	c graphql.Client
-
-	name  *string
+	// The environment variable name.
+	Name  string
+
-	value *string
+	// The environment variable value.
+	Value *string
}
-
-// The environment variable name.
-func (r *EnvVariable) Name(ctx context.Context) (string, error) {
-	if r.name != nil {
-		return *r.name, nil
-	}
-	q := r.q.Select("name")
-
-	var response string
-
-	q = q.Bind(&response)
-	return response, q.Execute(ctx, r.c)
-}
-
-// The environment variable value.
-func (r *EnvVariable) Value(ctx context.Context) (string, error) {
-	if r.value != nil {
-		return *r.value, nil
-	}
-	q := r.q.Select("value")
-
-	var response string
-
-	q = q.Bind(&response)
-	return response, q.Execute(ctx, r.c)
-}

Then, if a field returns a simple object, select all fields and use it directly in responses:
 // Retrieves the list of environment variables passed to commands.
 func (r *Container) EnvVariables(ctx context.Context) ([]EnvVariable, error) {
        q := r.q.Select("envVariables")

        q = q.Select("name value")

-       type envVariables struct {
-               Name  string
-               Value string
-       }
-
-       convert := func(fields []envVariables) []EnvVariable {
-               out := []EnvVariable{}
-
-               for i := range fields {
-                       out = append(out, EnvVariable{name: &fields[i].Name, value: &fields[i].Value})
-               }
-
-               return out
-       }
-       var response []envVariables
+       var response []EnvVariable

        q = q.Bind(&response)
-
-       err := q.Execute(ctx, r.c)
-       if err != nil {
-               return nil, err
-       }
-
-       return convert(response), nil
+       return response, q.Execute(ctx, r.c)
 }

We’re just moving that implementation detail to the outside, removing the need for passing context and capturing error.
Detection
With https://github.com/dagger/dagger/issues/5226, all SDKs should be able to reuse the same detection logic during introspection. But for now, I wrote a simple introspection command in Python to test the theory and as of now, these are the types that match:
"""A simple key value object that represents an environment variable."""
type EnvVariable {
  """The environment variable name."""
  name: String!

  """The environment variable value."""
  value: String!
}

"""A flag accepted by a project command."""
type ProjectCommandFlag {
  """Documentation for what this flag sets."""
  description: String

  """The name of the flag."""
  name: String!
}

"""A simple key value object that represents a label."""
type Label {
  """The label name."""
  name: String!

  """The label value."""
  value: String!

  """The transport layer network protocol."""
  protocol: NetworkProtocol!
}

See code that produced this 👆
from graphql import GraphQLNamedType, get_named_type
from graphql.utilities.print_schema import print_filtered_schema

import dagger
from dagger.codegen import (
    is_object_type,
    is_output_leaf_type,
)
from dagger.server import command

@command
def find(client: dagger.Client) -> str:
    """Find all simple objects in the schema."""
    schema = client._ctx.schema._schema
    out = print_filtered_schema(schema, lambda _: False, is_simple_object)
    print(out)
    return out

def is_simple_object(t: GraphQLNamedType) -> bool:
    t = get_named_type(t)
    if t.name.startswith("_") or not is_object_type(t):
        return False
    return not any(
        f
        for f_name, f in t.fields.items()
        if f_name == "id" or f.args or not is_output_leaf_type(f.type)
    )

Backwards compatibility
This is an obvious breaking change in SDKs (not in the API) because the signature for handling the above types is different. However, this is only a problem in Go but not in Python and Node.js because it doesn’t even work today (see more about this in Rationale: Handling lists of objects).
While we could introduce half measures to keep some sort of compatibility I think it’s better to just cluster this with other breaking changes we need to make in a single release.
Rationale
Handling lists of objects
There’s a long standing issue about SDKs not being able to return lists of objects:

https://github.com/dagger/dagger/issues/3457

Returning lists of objects were a known limitation in our chainable objects in the SDKs, so we had an undocumented convention for not supporting that until we had a good solution, but eventually it got into the API without having tests via the SDKs.
So to fix the introduced bug, @sipsma suggested:

If we are willing to trade more complexity for having the ability to return objects in lists maybe we could figure something out around autoselecting all trivial scalars for those cases, though I don't know if we'll have to apply that fix on a case-by-case basis (ugly) or if there's a way of cleanly generalizing it. Vague idea, might be a deadend, but in general it would be nice to support these return types.

- Reposted by @aluzzardi in https://github.com/dagger/dagger/issues/3457#issuecomment-1316112171
That idea has been adopted as the fix in Go:

https://github.com/dagger/dagger/pull/4683

However, the implementation isn’t ideal. When a list is returned, the fields are internally pre-selected and filled on private struct fields. When they are accessed, if the cached value exists then it’s short circuited:
type EnvVariable struct {
	// ...
	name  *string
	value *string
}

func (r *EnvVariable) Name(ctx context.Context) (string, error) {
	if r.name != nil {
		return *r.name, nil
	}
	// ...
}

func (r *EnvVariable) Value(ctx context.Context) (string, error) {
	if r.value != nil {
		return *r.value, nil
	}
	// ...
}

That means there’s useless verbosity when accessing these fields, i.e., context isn’t actually needed and the err is always nil:
name, err = env.Name(ctx)
if err != nil {
    return nil
}
value, err = env.Value(ctx)
if err != nil {
    return nil
}

You can ignore the errors in this case, but it’s an implementation detail and feels unsafe to depend on:
name, _ = env.Name(ctx)
value, _ = env.Value(ctx)

Yeah, I would have preferred to directly access the property instead of passing a context and unpacking the error but it's unfortunately not possible because of the current SDK API design :/

- Originally posted in https://github.com/dagger/dagger/pull/4683#issuecomment-1452262848
Meaning, this was desired instead:
name = env.Name
value = env.Value

I haven’t fixed this in Python yet because I wanted a better solution[^1], that’s why I came up with this proposal, which also solves some use cases for https://github.com/dagger/dagger/issues/3577.
[^1]: I no longer intend to wait on a solution to fix it in Python, just haven’t made it a priority yet but will soon.
Although it’s not that verbose in Python and Node.js:
name = await env.name()
value = await env.value()

# vs

name = env.name
value = env.value

But this proposal’s design would also works for any field that returns one of these objects directly, not just on lists of objects, which addresses the following concern:

Also creates a disparity between Object (need to call Object.Field(ctx) -- it's lazy) and [Object!]! (need to call Object.Field -- it's not lazy). We could have both APIs be the same, but the behavior would be different (lazy vs non-lazy) which can be confusing. Implementation would also need to be different (return "pre-fetched" field vs query the API).

- Originally posted by @aluzzardi in https://github.com/dagger/dagger/issues/3457#issuecomment-1316112171
I’m proposing that when these objects are returned, they’re always handled like a leaf, not just on lists.
Alternatives considered
SDK helper
At first I considered an SDK helper to hide the verbosity and boilerplate of making concurrent requests for the multiple sibling fields, but my pain point at the time was for getting exec related fields (i.e., exitCode, stdout, stderr). That’s why I added an ExecResult example to the first version of this proposal, but there’s been other solutions in the meantime.
Explicit declaration with API directive
GraphQL has input object types, used only as arguments to fields:
input BuildArg {
  name: String!
  value: String!
}

Codegen is already converting those into simple structs/objects:
type BuildArg struct {
	Name  string `json:"name"`
	Value string `json:"value"`
}

I would like to have an output EnvVariable {} type to do the same but for the return values. Since that doesn’t exist, we can simulate it with a directive:
directive @output on OBJECT

type EnvVariable @output {
  name: String!
  value: String!
}

Which would produce a similar struct/object to input types:
type EnvVariable struct {
	Name  string `json:"name"`
	Value string `json:"value"`
}

This solution makes detection much simpler in codegen and explicit in the API.
It’s not my first choice because it’s an added burden on API authors to choose correctly, potentially leaving some inconsistencies which would need extra validation in the API itself (e.g., using on a type that has non-leaf fields or fields with arguments, forgetting to use it in a new type and introducing a break in the convention….). But also when used in lists there’s an implicitness there already where this is actually required.
I chose to go with the implicit version because it’s better at enforcing the rules. However, this can become an option to have better control if in the future we find the need for it for any reason. By then, maybe other kinds of directives would be better, like marking a field as always being prefetched and used as a property, or marking a field as expensive so it gets ruled out as a property.
By then it won’t be a breaking change.
Alternative value object type
I thought about adding a second or alternative for these object types in the SDK clients, but that adds unnecessary fragmentation or inconsistency:
type EnvVariableValue struct {
	Name  string
	Value string
}

type EnvVariable struct {
	// ...
	name  *string
	value *string
}

func (r *EnvVariable) Name(ctx context.Context) (string, error) {
	// ...
}

func (r *EnvVariable) Value(ctx context.Context) (string, error) {
	// ...
}

Drawbacks

It’s a breaking change, but we can cluster it with other breaking changes.
Small benefit? Today we only have 4 object types with 2-3 fields but that’ll change (e.g., FileInfo).
We can find later on that we need more control over the selection (e.g., what if a leaf isn’t a “trivial” scalar?), but we can add directives if it comes to that.
Doesn’t entirely fix selecting sibling fields where a proper solution would fix this as well.
Doesn’t entirely fix returning lists of objects if you need to list an object that has at least one field that’s not a scalar.

Open question
There’s only one (very recent) case for the last point above in ProjectCommand, unless we include the id field (as a method) and also recursively resolve all the fields that list simple objects themselves. This isn’t hard to do, it’ll actually still make the implementation simpler compared to today. Would this be worth doing?
https://github.com/dagger/dagger/blob/3bb89e9ff1478077d271fa198d54edc96437487b/core/schema/project.graphqls#L30-L46

I just updated the proposal which was long overdue.

@helderco This issue can help to improve #5557 integration (See https://github.com/dagger/dagger/pull/5557#issuecomment-1687440697)
Should we start working on It, I understood your proposal and have an implementation in mind for Node and Go.
This would make our generators a bit more complex and specific (since we have special function for what you call simple object).

Should we start working on It?

We should agree on design first.

I kinda like the design proposed in your specification! I don't know if you have something different in mind for now?
We can have a quick sync chat if you're free to agree on the design :)

I meant we should get more feedback from the team if it's worthwhile considering the drawbacks and open question.

@vito @sipsma @shykes @aluzzardi Waiting for your feedbacks then :D

Sorry for the slow feedback on this! I think it's important; I've been thinking about related issues a lot lately, hoping something forces the issue, and it seems like this does, so yay!
I like your proposed solution the most, but there's one part that I'm hesitant about:

Doesn’t have an id field (rules out CacheVolume, Socket and Secret).

I'm hesitant here because as part of the Zenith spike I gave an ID to what is otherwise a simple object: EnvironmentCheckResult. It's ultimately just so that it can be serialized/deserialized in a typed way (Zenith also changes IDs to core.DirectoryID:eyJ...).
I'm not sure if we'll stick with that approach, but the fact that I had the option to once I made it ID-able makes me consider going full GraphQL purist and saying everything is a Node (has an id) and there is no such thing as a "simple data object." Another way of thinking about the above use case is that the Environment produced a DAG Node and needs to return its global database ID to the caller, which then loads the ID back into the Node.
At that point we could also unify on a single ID type, since the ID contains the type. We would probably want to do this, since "everything has an ID" + "every ID has its own type" would mean a ton more ID types.
But I still don't want to have to call methods just to get simple scalar static fields from a list of objects, so yeah, this is still important!
Could we do something like the @output directive but declared on individual fields rather than an entire type?
directive @field on FIELD_DEFINITION

type EnvironmentCheckResult {
  id: EnvironmentCheckResultID!

  name: String! @field # or @prefetch / @immutable / @static / @simple / 🤷♂
  withName(name: String!): EnvironmentCheckResult!

  success: Boolean! @field
  withSuccess(success: Boolean!): EnvironmentCheckResult!

  output: String! @field
  withOutput(output: String!): EnvironmentCheckResult!

  subresults: [EnvironmentCheckResult!] @field
  withSubresult(result: EnvironmentCheckResultID!): EnvironmentCheckResult!
}

Each SDK would then know to pre-fetch name, success, and output so they can be exposed on the struct:
type EnvironmentCheckResult {
  Name string
  Success bool
  Output string
}

func (res *EnvironmentCheckResult) ID(ctx context.Context) (EnvironmentCheckResultID, error) {
  // ...
}

I remember "ID-able vs. non-ID-able" being something we put a lot of leverage on, so this might be a game of jenga, but it seems worth exploring since it more closely aligns us with GraphQL.
It seems like there are a lot of benefits to "everything is a Node":

It's always easy to pass around anything in the DAG.

Even "simple objects" can just literally put all the info in the ID, like above.
In the future we could move things to a database if necessary. We've always talked about wanting to shrink these IDs.

We can add non-static methods to any type whenever we want to.

This is easy for methods that are wholly derived from the other fields.
Otherwise you might need to actually be using a database of some kind, but you can at least transition the ID to that when the time comes.

I should sleep, but there are probably more. 😅

Sidebar: I've also been wondering what the ID format should look like and what guarantees it should hold.  RFC-6920 is interesting. Another idea has been to indicate whether the ID refers to a "pure" value (contains no non-reproducible values like local dirs, secrets, etc). We would also want to decide if they are publicly shareable or if they are only valid within a session. Lots of overlap with #3923 too.

We just talked about this with @helderco & are thinking that we will come back to this Q1 2024. Leaving open for now. Needs further discussion.

@vito, I meant to reply before going on vacation in August but then forgot 😅. I'll reply soon.

Now that we have modules, with a distinction between fields and functions in an object, I’m much more inclined to the explicit @field directive approach. In the CLI we want to be able to print the fields of an object instead of returning an error when the chain ends in one:

https://github.com/dagger/dagger/issues/6515

That, however, is only available to user modules because core doesn’t have this distinction in its object types. GraphQL objects only have fields. Today we'd need to hardcode special handling.
To support core chaining in the CLI, core types are being TypeDef’ed, also in preparation of making core a module in the future. At the moment, all core objects have only functions. With @field we would be declaring which ones can be a module field. I should probably put this into a separate issue, more focused on the module representation aspect, and keep this one focused on the SDK DX of returning an object with pre-populated fields. These two concepts overlap, but I haven’t spent enough time checking if they’re compatible together.
Simple rules/validation for choosing where to put a @field:

Doesn’t have any arguments;
Returns a “trivial” value;
Think “state”;

Returning a string scalar isn’t enough. It has to be something that’s not expensive to return; however, this needs to be discerned by the maintainer. For example, Container.stdout returns a string, but it triggers execution, which can take a long time. It’s excluded anyway since it takes arguments.
Anything in Container that returns something from ImageConfig is “static” though, so it’s easy to fetch (user, workdir, env vars, exposed ports, labels, default command…). For File you have name and size. For these kinds of objects, “trivial” means metadata. For a simple object like EnvVariable it’s the actual data.

We don't want a distinction between field and function. It doesn't exist in the underlying graphql spec, and it would be unnecessary cognitive load for developers to try to understand the difference.

This distinction wouldn't show in the DX, not as fields anyway. It's just a way to mark some graphql fields as "trivial" and allow some optimizations, particularly pre-selecting in certain cases like on lists or when printing a core object in the CLI.

Don't we already have a distinction in the DX for modules in particular? In the Go SDK for example you have fields on the struct for an object, while functions are methods on the object. How would you manage state without a fields vs. functions distinction?

Indeed. When we turn core into typedefs, they're all functions, no declared "state". When a module with fields extends the schema, they become functions without arguments. We could preserve this information with the directive.

For continuity from Discord conversations with @shykes:
We agree that there's a need for state and that there is effectively a fields vs. functions distinction internally, but @shykes 's point is that fields should just be an implementation detail of modules, not distinguished in any way through the API. The main take-away is that it should be easy for a module author to switch something from a field to a function internally without any impact on users.
So I think to address this we'll need better client support for selecting multiple fields. Right now you have to drop down to a handwritten query string. We could explore a totally different style of client based on a query building approach - there's consensus in curiosity, but not commitment. Or maybe there's a middle ground where we can integrate multiple field selection into the existing SDK in a natural way.

We could explore a totally different style of client based on a query building approach

I summarized that in https://github.com/dagger/dagger/issues/4668#multiple. By that I mean separating query building from execution, as in:
// build query, doesn't execute
q := dag.Container().Build(src).Stdout()

// only one way to execute query!
err := dagger.Query(q)

From my POV, the big issue with that approach was we didn't find a good way to extract multiple values, from a multiple selection. Solomon had a few ideas but they didn't cross language very well. We were a bit stuck discussing this (see https://github.com/dagger/dagger/issues/3555#issuecomment-1301327344), so it was decided at the time to just move on with the more simple solution, which is what we have today.
After a while, when people were expressing confusion over the implicitness of execution on leafs, contrary to just building a query, we were thinking that the query builder approach could make it easier to understand for people, but also that it was too big a change and it was too late.

Or maybe there's a middle ground where we can integrate multiple field selection into the existing SDK in a natural way.

Yeah, in the meantime, this often pops up in my head, i.e., selecting multiple siblings with the current DX, but the thought is like a doctor's visit, which doesn't stay long. 😄
I usually gravitate towards something to the tune of generating a second object type for each object type, that only includes the leafs but still chainable to allow for multiple selection:
ctr, err := dag.Container().
    From("alpine").
    WithExec([]string{"printenv"}).
    Leafs().  // bikeshedding non-withdstanding
    Stdout().
    Stderr().
    Sync(ctx)  // or anything else to Execute

Essentially there would be a Container.Leafs -> &ContainerLeafs{} where ContainerLeafs.Stdout() just adds the sibling selection to the query builder and returns "self", like the other non-leafs.
At this point, when I need to figure out the best way to get the multiple values in a way that is type safe and has a good DX over multiple languages, my 🧠 jumps to another branch in the 🐒 🌴. 🙂


fix bug store framework ID failed

Current coverage is 43.18% (diff: 100%)

Merging #73 into master will increase coverage by 0.10%

@@             master        #73   diff @@
==========================================
  Files            34         34
  Lines         10436      10436
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           4496       4507    +11
+ Misses         4900       4868    -32
- Partials       1040       1061    +21

Powered by Codecov. Last update ee43abc...02d05f6

LGTM


Using PyOrient in Multi-process approaches

Can I use the same instance of client object concurrently.
ie,
I have several objects that need persist and query data in Orientdb.
All of them work concurrently.
Can I create only one instance of Client Object and share it with all of them?

Hi @hrugani ,
i've not tested concurrency, but i thik it should be safe. By the way, the socket connection is only one and all your concurrent objects will be serialized ( as for a pipeline ) because a connection pool is not implemented in the driver. So you can loose the performance advantages of the concurrency.

Thank you for your feedback.

FWIW, I had issues using pyorient in celery workers when using the default multiprocessing for concurrency, but using eventlet for concurrency did work. YMMV. With multiprocessing, if two workers tried to access the database simultaneously they would both lock up when calling select() on the orient socket, and further workers would get "resource temporarily unavailable." After switching to eventlet, I can't duplicate the issue (and indeed, when two workers run at the same time, I instead get duplicate record errors as would be expected).

mmm you're telling me that the socket is a static resource? ( in such a case it would be a bug )
I imagine a pool handling some clients in this way:
<pseudocode>
for i in 50:
   pool += new client

pool[1].connect()
pool[2].connect()

and they should work indipendently and thread safe. If this is not the case the code must be fixed


Update zio, zio-test, zio-test-sbt to 2.0.14

About this PR
📦 Updates

dev.zio:zio
dev.zio:zio-test
dev.zio:zio-test-sbt

from 2.0.2 to 2.0.14
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "dev.zio" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "dev.zio" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #498.


Fix typo in Fortran demo

In Fortran demo page, it is stated that text/x-Fortran MIME type is defined, while the correct MIME type is with lowercase f

Thanks! Merged as 90d8250


fix mosn example image

fix #889
mosn image is just a example. Usually, we just run example with binary, not image
make build  && make image
docker run -dit ${docker image}

Codecov Report

Merging #890 into stable will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           stable     #890      +/-   ##
==========================================
+ Coverage   55.65%   55.66%   +<.01%
==========================================
  Files         234      234
  Lines       23795    23795
==========================================
+ Hits        13243    13245       +2
  Misses       9336     9336
+ Partials     1216     1214       -2

Impacted Files
Coverage Δ

pkg/log/logger.go
55.08% <0%> (-1.61%)
:arrow_down:

pkg/module/http2/server.go
81.7% <0%> (+0.07%)
:arrow_up:

pkg/module/http2/transport.go
78.88% <0%> (+0.29%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 733c819...aed408b. Read the comment docs.


[fix] Memory leaks when compaction fails

Proposed changes
Issue Number: close #15427
Problem summary
340 OLAPStatus CollectIterator::Level1Iterator::init() {
341     if (_children.empty()) {
342         return OLAP_SUCCESS;
343     }
344
345     // Only when there are multiple children that need to be merged
346     if (_merge && _children.size() > 1) {
347         std::shared_ptr<LevelIteratorComparator> cmp;
348         if (_sort_type == SortType::ZORDER) {
349             cmp = std::make_shared<LevelZorderIteratorComparator>(_reverse, _sequence_id_idx,  _sort_col_num);
350         } else {
351             cmp = std::make_shared<LevelIteratorComparator>(_reverse, _sequence_id_idx);
352         }
353         BaseComparator bcmp(cmp);
354         _heap.reset(new MergeHeap(bcmp));
355         for (auto child : _children) {
356             DCHECK(child != nullptr);
357             DCHECK(child->current_row() != nullptr);
358             _heap->push(child);
359         }
360         _cur_child = _heap->top();
361         // Clear _children earlier to release any related references
362         _children.clear();
363     } else {
364         _merge = false;
365         _heap.reset(nullptr);
366         _cur_child = *(_children.begin());
367     }
368     return OLAP_SUCCESS;
369 }

In function CollectIterator::Level1Iterator::init, _children are pushed into _heap and cleared in line 362 which means that the ownership of _children belongs to _heap.
371 inline OLAPStatus CollectIterator::Level1Iterator::_merge_next(const RowCursor** row,
372                                                                bool* delete_flag) {
373     _heap->pop();
374     auto res = _cur_child->next(row, delete_flag);
375     if (LIKELY(res == OLAP_SUCCESS)) {
376         _heap->push(_cur_child);
377         _cur_child = _heap->top();
378     } else if (res == OLAP_ERR_DATA_EOF) {
379         // current child has been read, to read next
380         delete _cur_child;
381         if (!_heap->empty()) {
382             _cur_child = _heap->top();
383         } else {
384             _cur_child = nullptr;
385             return OLAP_ERR_DATA_EOF;
386         }
387     } else {
388         _cur_child = nullptr;
389         LOG(WARNING) << "failed to get next from child, res=" << res;
390         return res;
391     }
392
393     if (_cur_child->need_skip()) {
394         (*_merged_rows)++;
395         _cur_child->set_need_skip(false);
396         return _merge_next(row, delete_flag);
397     }
398     *row = _cur_child->current_row(delete_flag);
399     return OLAP_SUCCESS;
400 }

In CollectIterator::Level1Iterator::_merge_next, _heap pops the top element first and _cur_child references to the top. If we entered the branch line 388 (failed to call next before), we didn't free the memory of _cur_child which causes the issue with memory leak.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[x] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[x] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[x] No Need

Does it need to update dependencies:

[ ] Yes
[x] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[x] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

@adonis0147 Excuse me, I would like to ask a question, when get_next from child fails in the _normal_next function, also should delete _cur_child?

 @adonis0147 Excuse me, I would like to ask a question, when get_next from child fails in the _normal_next function, also should delete _cur_child?

In this case, I don't think we should do delete _cur_child, because the destructor CollectIterator::Level1Iterator::~Level1Iterator reclaims these memory. Unlike merge, there are no ownership transferring in OLAPStatus CollectIterator::Level1Iterator::init if we do normal scan.

Hi @zenoyang , in this case, I don't think we should do delete _cur_child, because the destructor CollectIterator::Level1Iterator::~Level1Iterator reclaims these memory. Unlike merge, there are no ownership transferring in OLAPStatus CollectIterator::Level1Iterator::init if we do normal scan.

I understand, thank you for your answer


Change the InterfaceMap from a std::map to std::unordered_map

Codecov Report

Merging #345 into development will increase coverage by 0.05%.
The diff coverage is 100%.

@@               Coverage Diff               @@
##           development     #345      +/-   ##
===============================================
+ Coverage        89.28%   89.34%   +0.05%
===============================================
  Files               89       89
  Lines             6225     6250      +25
===============================================
+ Hits              5558     5584      +26
+ Misses             667      666       -1

Impacted Files
Coverage Δ

...mework/include/cppmicroservices/ServiceInterface.h
96.29% <100%> (ø)
:arrow_up:

framework/src/util/FrameworkPrivate.cpp
77.91% <0%> (+0.61%)
:arrow_up:

framework/include/cppmicroservices/BundleContext.h
97.4% <0%> (+1.24%)
:arrow_up:


Enemies sliders not working properly

Version
3.0.5 ~ 3.0.6
Seed
Every
Scenario
RE 2 (Claire B)
Player Character
Every
What happened?
I've played a lot of seeds with Leon A and now Claire B, don't know what happened, but I don't wanna a hard-core game so I put zombies at high, cerberus in the middle, crows 2 positions ahead of none and all the others at position 1. For some reasons it only appears Ivy, spiders, Mr X, hands and Birkir everywhere. One or two zombies rom in the hole game. What is going on??
Now I tried to make inverted with Claire B, and put all of them at high, except zombies which are at low.
How the sliders are supposed to work?

Can you give me an example of a seed?

R720-RG26-XXU7307Z1Y000V9H30K0ZZZZZZZZZZZZXFZ
I just created this seed now. I'm using Nemesis/Birkin/Tyrant add-on, but I swear this problem was already happening before I installed those new playable characters.
Take a look at some log lines from Claire B:
Randomizing enemies:
Created 10A:0 (0x0) [ZombieArms,0,0,17,0] at (-25669,0,-6991)
Created 10A:1 (0x0) [ZombieArms,0,0,17,0] at (-24601,0,-12326)
Created 10A:2 (0x0) [ZombieArms,0,0,17,0] at (-24315,0,-24780)
Created 10A:3 (0x0) [ZombieArms,0,0,17,0] at (-26396,0,-24774)
Created 10A:4 (0x0) [ZombieArms,0,0,17,0] at (-25472,0,-14388)
Created 10A:5 (0x0) [ZombieArms,0,0,17,0] at (-20622,0,-7391)
Created 60E:7 (0x0) [Crow,0,0,13,0] at (-22788,-18000,-2812)
Created 60E:9 (0x0) [Crow,0,0,13,0] at (-22957,-18000,-21240)
Created 60E:10 (0x0) [Crow,0,0,13,0] at (-22795,-18000,-25825)
Created 501:0 (0x0) [ZombieDog,0,0,12,0] at (24801,0,-18885)
Created 501:1 (0x0) [ZombieDog,0,0,12,0] at (19300,0,-19317)
Created 110:0 (0x0) [Tyrant1,0,0,18,0] at (-3607,-7200,-7506)
Created 110:1 (0x0) [Tyrant1,0,0,18,0] at (-1524,-7200,11763)
Created 600:0 (0x0) [ZombieBrad,3,0,1,0] at (-3824,0,-17033)
Created 600:1 (0x0) [ZombieBrad,0,0,1,0] at (238,0,-9894)
Created 600:2 (0x0) [ZombieBrad,1,0,1,0] at (4141,0,-23279)
Created 600:3 (0x0) [ZombieBrad,0,0,1,0] at (8710,0,-9755)
Created 600:4 (0x0) [ZombieBrad,3,0,1,0] at (11117,0,-23144)
Created 600:5 (0x0) [ZombieBrad,6,0,1,0] at (-10507,-1800,-17217)
Created 60B:1 (0x0) [ZombieArms,0,0,17,0] at (-9592,0,-24291)
Created 60B:2 (0x0) [ZombieArms,0,0,17,0] at (-18590,0,-14464)
Created 60B:3 (0x0) [ZombieArms,0,0,17,0] at (-22897,0,-11368)
Created 60B:4 (0x0) [ZombieArms,0,0,17,0] at (-14996,0,-18772)
Created 60B:5 (0x0) [ZombieArms,0,0,17,0] at (-10691,0,-22421)
Created 60B:6 (0x0) [ZombieArms,0,0,17,0] at (-16267,0,-16673)
Created 60F:0 (0x0) [Crow,0,0,13,0] at (-23255,0,-16051)
Created 60F:1 (0x0) [Crow,0,0,13,0] at (-20774,0,-20080)
Created 60F:2 (0x0) [Crow,0,0,13,0] at (-18685,0,-18952)
Created 60F:3 (0x0) [Crow,0,0,13,0] at (-13533,0,-23542)
Created 60F:4 (0x0) [Crow,0,0,13,0] at (-16528,0,-22438)
Created 214:0 (0x0) [ZombieDog,0,0,12,0] at (-15808,0,-15020)
Created 214:1 (0x0) [ZombieDog,0,0,12,0] at (-15800,0,-8348)
Created 105:0 (0x0) [Tyrant1,0,0,18,0] at (20923,0,-12571)
Created 105:1 (0x0) [Tyrant1,0,0,18,0] at (-8304,0,-15463)
20E:2 (0x0) [LickerRed,0,0,14,0] becomes [ZombieScientist,0,0,1,0]
20E:3 (0x0) [LickerRed,2,5,14,0] becomes [ZombieScientist,1,0,1,0]
Created 613:0 (0x0) [ZombieArms,0,0,17,0] at (-18679,0,-23344)
Created 613:1 (0x0) [ZombieArms,0,0,17,0] at (-23644,0,-22869)
Created 613:8 (0x0) [ZombieArms,0,0,17,0] at (-12474,0,-18724)
Created 613:9 (0x0) [ZombieArms,0,0,17,0] at (-17572,0,-19684)

Created 104:0 (0x0) [Crow,0,0,13,0] at (14410,0,-23028)
Created 104:1 (0x0) [Crow,0,0,13,0] at (-4955,0,-20918)
Created 203:0 (0x0) [ZombieDog,0,0,12,0] at (-24000,0,-24031)
Created 203:1 (0x0) [ZombieDog,0,0,12,0] at (-19791,0,-15935)
Created 304:0 (0x0) [Tyrant1,0,0,18,0] at (-15996,0,-25686)
210:0 (0x0) [ZombieCop,2,64,0,0] becomes [ZombieBrad,2,0,1,0]
Created 216:0 (0x0) [ZombieArms,0,0,17,0] at (-18112,0,-195)
Created 216:1 (0x0) [ZombieArms,0,0,17,0] at (-13056,0,-5468)
Created 216:2 (0x0) [ZombieArms,0,0,17,0] at (-19322,0,5137)
Created 216:3 (0x0) [ZombieArms,0,0,17,0] at (1448,0,-2168)
Created 216:4 (0x0) [ZombieArms,0,0,17,0] at (-5092,0,-4680)
Created 216:5 (0x0) [ZombieArms,0,0,17,0] at (-14656,0,3241)
Created 216:6 (0x0) [ZombieArms,0,0,17,0] at (-15729,0,13137)
Created 602:0 (0x0) [Crow,0,0,13,0] at (-10822,0,-15937)
Created 602:1 (0x0) [Crow,0,0,13,0] at (-14125,0,-1586)
Created 602:2 (0x0) [Crow,0,0,13,0] at (-10188,0,-10116)
Created 506:0 (0x0) [ZombieDog,0,0,12,0] at (-3083,-14400,-22298)
Created 506:1 (0x0) [ZombieDog,0,0,12,0] at (-8572,-19800,-17259)
Created 60C:0 (0x0) [Tyrant1,0,0,18,0] at (17393,0,-14752)
Created 60C:1 (0x0) [Tyrant1,0,0,18,0] at (22829,0,-11003)

Created 209:0 (0x0) [ZombieArms,0,0,17,0] at (-22813,0,-20421)
Created 209:1 (0x0) [ZombieArms,0,0,17,0] at (-21411,0,-24506)
Created 209:2 (0x0) [ZombieArms,0,0,17,0] at (-19387,0,-15562)
Created 209:3 (0x0) [ZombieArms,0,0,17,0] at (-25356,0,-23922)
Created 209:4 (0x0) [ZombieArms,0,0,17,0] at (-17475,0,-20771)
Created 209:5 (0x0) [ZombieArms,0,0,17,0] at (-21073,0,-19535)
Created 209:6 (0x0) [ZombieArms,0,0,17,0] at (-16935,0,-26162)
Created 213:0 (0x0) [Crow,0,0,13,0] at (-13534,0,-19611)
Created 213:1 (0x0) [Crow,0,0,13,0] at (-23710,0,-23289)
Created 213:2 (0x0) [Crow,0,0,13,0] at (-15418,0,-24063)
Created 502:0 (0x0) [ZombieDog,0,0,12,0] at (-15962,0,-14558)
Created 502:1 (0x0) [ZombieDog,0,0,12,0] at (-14705,0,-21248)
Created 30B:0 (0x0) [Tyrant1,0,0,18,0] at (-11937,0,-6211)
Created 30B:1 (0x0) [Tyrant1,0,0,18,0] at (-16866,0,-9218)
Created 109:1 (0x0) [ZombieNaked,6,0,46,0] at (-9846,0,-12051)
Created 109:2 (0x0) [ZombieNaked,3,0,46,0] at (-1878,0,-6054)
Created 109:3 (0x0) [ZombieNaked,1,0,46,0] at (-21099,0,-25509)
Created 109:4 (0x0) [ZombieNaked,0,0,46,0] at (-13904,0,-22167)
Created 109:5 (0x0) [ZombieNaked,6,0,46,0] at (-14803,0,-13427)
Created 109:6 (0x0) [ZombieNaked,0,0,46,0] at (-12133,0,-9899)
Created 109:7 (0x0) [ZombieNaked,3,0,46,0] at (-25991,0,-24786)
Created 109:8 (0x0) [ZombieNaked,3,0,46,0] at (-5517,0,-13174)
Created 109:9 (0x0) [ZombieNaked,6,0,46,0] at (-1860,0,-11894)
Created 109:10 (0x0) [ZombieNaked,6,0,46,0] at (-18425,0,-24678)

Created 205:1 (0x0) [ZombieArms,0,0,17,0] at (-24432,0,-22982)
Created 205:2 (0x0) [ZombieArms,0,0,17,0] at (-20302,0,-8713)
Created 205:3 (0x0) [ZombieArms,0,0,17,0] at (-8586,0,-10709)
Created 205:4 (0x0) [ZombieArms,0,0,17,0] at (-13167,0,-8770)
Created 205:5 (0x0) [ZombieArms,0,0,17,0] at (-7235,0,-16722)
Created 205:6 (0x0) [ZombieArms,0,0,17,0] at (-25617,0,-16714)
Created 205:7 (0x0) [ZombieArms,0,0,17,0] at (-22723,0,-8724)
Created 20A:0 (0x0) [Crow,0,0,13,0] at (-13396,0,-395)
Created 20A:1 (0x0) [Crow,0,0,13,0] at (-9458,0,336)
Created 20A:2 (0x0) [Crow,0,0,13,0] at (-10620,0,4218)
Created 20A:3 (0x0) [Crow,0,0,13,0] at (-13896,0,3466)
Created 111:0 (0x0) [ZombieDog,0,0,12,0] at (-19900,-5400,-27500)
609:0 (0x0) [LickerGrey,0,0,51,0] becomes [Tyrant1,0,0,18,0]
609:1 (0x0) [LickerGrey,0,0,51,0] becomes [Tyrant1,0,0,18,0]
Created 20B:1 (0x0) [ZombieBrad,3,0,1,0] at (-8377,0,-17003)
Created 20B:2 (0x0) [ZombieBrad,4,0,1,0] at (-22737,0,-15003)
Created 20B:3 (0x0) [ZombieBrad,1,0,1,0] at (-17401,0,-18978)
Created 20B:4 (0x0) [ZombieBrad,0,0,1,0] at (-24451,0,-26041)
Created 20B:5 (0x0) [ZombieBrad,1,0,1,0] at (-7221,0,-19841)
Created 20B:6 (0x0) [ZombieBrad,4,0,1,0] at (-14143,0,-25746)
Created 20B:7 (0x0) [ZombieBrad,2,0,1,0] at (-15952,0,-8777)
Created 20B:8 (0x0) [ZombieBrad,2,0,1,0] at (-14432,0,-14260)
Created 20B:9 (0x0) [ZombieBrad,6,0,1,0] at (-4889,0,-13748)
Created 20B:10 (0x0) [ZombieBrad,2,0,1,0] at (-10113,0,-14217)

Created 10B:0 (0x0) [ZombieArms,0,0,17,0] at (-22995,0,-14100)
Created 10B:1 (0x0) [ZombieArms,0,0,17,0] at (-19709,0,-23945)
Created 10B:2 (0x0) [ZombieArms,0,0,17,0] at (-21445,0,-20331)
Created 10B:3 (0x0) [ZombieArms,0,0,17,0] at (-21723,0,-15115)
407:0 (0x788) [Spider,67,0,16,0] becomes [Crow,0,0,13,0]
407:1 (0x79E) [Spider,67,0,16,0] becomes [Crow,0,0,13,0]
Created 60D:1 (0x0) [ZombieDog,0,0,12,0] at (-26019,0,-15814)
Created 60D:2 (0x0) [ZombieDog,0,0,12,0] at (-25235,0,-16443)
Created 207:0 (0x0) [Tyrant1,0,0,18,0] at (-24396,0,-21681)
Created 207:1 (0x0) [Tyrant1,0,0,18,0] at (-20468,0,-11067)
Created 116:0 (0x0) [ZombieBrad,6,0,1,0] at (-15365,0,-24839)
Created 116:1 (0x0) [ZombieBrad,3,0,1,0] at (-20772,0,-25169)
405:0 (0xF9A) [ZombieGuy1,0,0,37,0] becomes [ZombieArms,0,0,17,0]
405:1 (0xFB0) [ZombieGuy1,0,0,37,0] becomes [ZombieArms,0,0,17,0]
405:2 (0xFC6) [ZombieGuy1,0,0,37,0] becomes [ZombieArms,0,0,17,0]
405:0 (0xFE0) [ZombieGuy1,0,0,3,0] becomes [ZombieArms,0,0,17,0]
405:1 (0xFF6) [ZombieGuy1,0,0,3,0] becomes [ZombieArms,0,0,17,0]
405:2 (0x100C) [ZombieGuy1,0,0,3,0] becomes [ZombieArms,0,0,17,0]
405:0 (0x1044) [ZombieGuy1,2,64,37,0] becomes [ZombieArms,0,0,17,0]
405:1 (0x105A) [ZombieGuy1,4,64,37,0] becomes [ZombieArms,0,0,17,0]
405:2 (0x1070) [ZombieGuy1,4,64,37,0] becomes [ZombieArms,0,0,17,0]
405:0 (0x108A) [ZombieGuy1,2,64,3,0] becomes [ZombieArms,0,0,17,0]
405:1 (0x10A0) [ZombieGuy1,4,64,3,0] becomes [ZombieArms,0,0,17,0]
405:2 (0x10B6) [ZombieGuy1,4,64,3,0] becomes [ZombieArms,0,0,17,0]
405:0 (0x10D4) [Spider,75,0,16,0] becomes [ZombieArms,0,0,17,0]
405:1 (0x10EA) [Spider,67,0,16,0] becomes [ZombieArms,0,0,17,0]
113:0 (0x10B4) [ZombieRandom,4,128,5,2] becomes [Crow,0,0,13,0]
113:1 (0x10DC) [ZombieRandom,8,64,5,3] becomes [Crow,0,0,13,0]
113:2 (0x10F2) [ZombieRandom,8,64,5,3] becomes [Crow,0,0,13,0]
113:3 (0x1108) [ZombieRandom,8,64,6,3] becomes [Crow,0,0,13,0]
113:4 (0x111E) [ZombieRandom,8,64,6,3] becomes [Crow,0,0,13,0]
113:1 (0x114C) [ZombieRandom,6,0,5,3] becomes [Crow,0,0,13,0]
113:2 (0x1162) [ZombieRandom,6,0,5,3] becomes [Crow,0,0,13,0]
113:3 (0x1178) [ZombieRandom,0,0,6,3] becomes [Crow,0,0,13,0]
113:4 (0x118E) [ZombieRandom,0,0,6,3] becomes [Crow,0,0,13,0]
113:0 (0x123C) [ZombieRandom,4,128,5,2] becomes [Crow,0,0,13,0]
113:1 (0x1264) [ZombieRandom,8,64,5,3] becomes [Crow,0,0,13,0]
113:2 (0x127A) [ZombieRandom,8,64,5,3] becomes [Crow,0,0,13,0]
113:3 (0x1290) [ZombieRandom,8,64,6,3] becomes [Crow,0,0,13,0]
113:4 (0x12A6) [ZombieRandom,8,64,6,3] becomes [Crow,0,0,13,0]
113:5 (0x12BC) [ZombieRandom,8,64,6,3] becomes [Crow,0,0,13,0]
113:1 (0x12EA) [ZombieRandom,6,0,5,3] becomes [Crow,0,0,13,0]
113:2 (0x1300) [ZombieRandom,6,0,5,3] becomes [Crow,0,0,13,0]
113:3 (0x1316) [ZombieRandom,0,0,6,3] becomes [Crow,0,0,13,0]
113:4 (0x132C) [ZombieRandom,0,0,6,3] becomes [Crow,0,0,13,0]
113:5 (0x1342) [ZombieRandom,0,0,6,3] becomes [Crow,0,0,13,0]
113:0 (0x2038) [LickerGrey,0,0,14,0] becomes [Crow,0,0,13,0]
113:1 (0x204E) [LickerGrey,0,0,14,0] becomes [Crow,0,0,13,0]
113:2 (0x2064) [LickerGrey,0,0,14,0] becomes [Crow,0,0,13,0]
40D (0xF2C) opcode removed
Created 40D:0 (0x0) [ZombieDog,0,0,12,0] at (-20967,-1800,-25758)
Created 40D:1 (0x0) [ZombieDog,0,0,12,0] at (-26092,-1058,-20300)
Created 305:0 (0x0) [Tyrant1,0,0,18,0] at (-8134,-5400,-17864)
Created 305:1 (0x0) [Tyrant1,0,0,18,0] at (-21781,-5400,-17232)
Created 20F:0 (0x0) [ZombieTestSubject,6,0,1,0] at (-25804,0,-3956)
Created 20F:1 (0x0) [ZombieTestSubject,4,0,1,0] at (-22466,0,-23564)
Created 20F:2 (0x0) [ZombieTestSubject,3,0,1,0] at (-18922,0,-5377)
Created 20F:3 (0x0) [ZombieTestSubject,6,0,1,0] at (-17560,0,-24851)
Created 20F:4 (0x0) [ZombieTestSubject,0,0,1,0] at (-17405,0,-25761)
Created 20F:5 (0x0) [ZombieTestSubject,6,0,1,0] at (-17255,0,-11386)
Created 103:0 (0x0) [ZombieArms,0,0,17,0] at (23741,-5400,-24033)
Created 103:1 (0x0) [ZombieArms,0,0,17,0] at (13499,-5400,-9537)
Created 103:2 (0x0) [ZombieArms,0,0,17,0] at (14289,-5400,-11571)
Created 103:3 (0x0) [ZombieArms,0,0,17,0] at (-15132,-5400,-20379)
60A:0 (0x12F8) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:1 (0x130E) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:2 (0x1324) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:3 (0x133A) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:4 (0x1350) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:5 (0x1366) [Vines,0,32,48,0] becomes [Vines,0,32,0,0]
60A:0 (0x137E) [ZombieNaked,0,0,46,0] becomes [Crow,0,0,13,0]
60A:1 (0x1394) [ZombieNaked,0,0,46,0] becomes [Crow,0,0,13,0]
60A:2 (0x13AA) [ZombieNaked,6,0,46,0] becomes [Crow,0,0,13,0]
Created 301:1 (0x0) [ZombieDog,0,0,12,0] at (-18467,0,-27714)

Created 112:0 (0x0) [Tyrant1,0,0,18,0] at (-10333,0,-22935)
Created 112:1 (0x0) [Tyrant1,0,0,18,0] at (-12818,-5400,-12853)

Created 616:0 (0x0) [ZombieRandom,1,0,1,0] at (-13259,0,-3444)
Created 616:1 (0x0) [ZombieRandom,6,0,1,0] at (-11569,0,-12403)
Created 616:2 (0x0) [ZombieRandom,0,0,1,0] at (1563,0,-12964)
Created 616:3 (0x0) [ZombieRandom,4,0,1,0] at (-25674,0,-25507)
Created 616:4 (0x0) [ZombieRandom,6,0,1,0] at (-11999,0,-25588)
Created 616:5 (0x0) [ZombieRandom,4,0,1,0] at (-15141,0,-8334)
Created 616:6 (0x0) [ZombieRandom,2,0,1,0] at (-9248,0,-20748)
Created 616:7 (0x0) [ZombieRandom,4,0,1,0] at (6897,0,-12964)
Created 616:8 (0x0) [ZombieRandom,2,0,1,0] at (-12174,0,-16861)
Created 616:9 (0x0) [ZombieRandom,4,0,1,0] at (-11106,0,-21657)
Created 306:0 (0x0) [Crow,0,0,13,0] at (-22596,0,-22094)
Created 306:1 (0x0) [Crow,0,0,13,0] at (-18375,-5400,-21403)
Created 211:0 (0x0) [ZombieDog,0,0,12,0] at (-18006,0,-13496)
Created 211:1 (0x0) [ZombieDog,0,0,12,0] at (-25144,0,-14139)
Created 10D:1 (0x0) [Tyrant1,0,0,18,0] at (-25457,0,-19396)
Created 10D:2 (0x0) [Tyrant1,0,0,18,0] at (-25738,0,-14640)
Created 402:0 (0x0) [ZombieTestSubject,4,0,1,0] at (-15612,0,-10858)
Created 402:1 (0x0) [ZombieTestSubject,1,0,1,0] at (-19160,-1800,-10502)
Created 402:2 (0x0) [ZombieTestSubject,3,0,1,0] at (-17212,0,-6727)
Created 402:3 (0x0) [ZombieTestSubject,4,0,1,0] at (-16977,0,-15133)
Created 402:4 (0x0) [ZombieTestSubject,0,0,1,0] at (-15149,0,-21433)
Created 219:0 (0x0) [ZombieArms,0,0,17,0] at (-6036,0,-21227)
Created 219:1 (0x0) [ZombieArms,0,0,17,0] at (-19236,0,-14050)
Created 219:2 (0x0) [ZombieArms,0,0,17,0] at (-168,0,-19759)
Created 219:3 (0x0) [ZombieArms,0,0,17,0] at (-4758,0,-16039)
Created 219:4 (0x0) [ZombieArms,0,0,17,0] at (-10905,0,-12756)
605:0 (0x0) [LickerGrey,0,0,51,0] becomes [ZombieDog,0,0,12,0]
605:1 (0x0) [LickerGrey,0,0,51,0] becomes [ZombieDog,0,0,12,0]
Created 409:0 (0x0) [Tyrant1,0,0,18,0] at (-8721,-10800,-569)
Created 409:1 (0x0) [Tyrant1,0,0,18,0] at (6592,-7200,-6128)
Created 215:0 (0x0) [ZombieRandom,6,0,1,0] at (-21397,0,-14511)
Created 215:1 (0x0) [ZombieRandom,4,0,1,0] at (-24461,0,-13190)
Created 215:2 (0x0) [ZombieRandom,0,0,1,0] at (-25887,0,-19397)
Created 215:3 (0x0) [ZombieRandom,1,0,1,0] at (-15808,0,-15020)
Created 215:4 (0x0) [ZombieRandom,4,0,1,0] at (-20857,0,-22146)
Created 615:0 (0x0) [ZombieArms,0,0,17,0] at (-24481,0,-24515)
Created 615:1 (0x0) [ZombieArms,0,0,17,0] at (-21160,0,-20411)
Created 615:2 (0x0) [ZombieArms,0,0,17,0] at (-13206,0,-19932)
Created 107:0 (0x0) [Crow,0,0,13,0] at (1629,0,-11547)
Created 610:0 (0x0) [ZombieDog,0,0,12,0] at (-18649,0,-21478)
Created 610:1 (0x0) [ZombieDog,0,0,12,0] at (-17695,0,-23619)
Created 20C:1 (0x0) [Tyrant1,0,0,18,0] at (-10338,0,-14824)
Created 20C:2 (0x0) [Tyrant1,0,0,18,0] at (-17972,0,-8809)
212 (0x8C2) opcode removed
Created 212:0 (0x0) [ZombieCop,3,0,1,0] at (-11594,0,-9830)
Created 212:1 (0x0) [ZombieCop,3,0,1,0] at (-19984,0,-9864)
Created 212:2 (0x0) [ZombieCop,2,0,1,0] at (-10597,0,-18845)
Created 10C:1 (0x0) [ZombieArms,0,0,17,0] at (-21592,-3600,-15032)
Created 10C:2 (0x0) [ZombieArms,0,0,17,0] at (-24326,-3600,-10020)
Created 10C:3 (0x0) [ZombieArms,0,0,17,0] at (2426,-3600,-6980)
21A:0 (0x1B58) [ZombieDog,7,0,12,0] becomes [Crow,0,0,13,0]
21A:1 (0x1B94) [ZombieDog,8,0,12,0] becomes [Crow,0,0,13,0]
21A:1 (0x1BAE) [ZombieDog,7,0,12,0] becomes [Crow,0,0,13,0]
21A:0 (0x1C1A) [ZombieDog,0,0,12,0] becomes [Crow,0,0,13,0]
21A:1 (0x1C30) [ZombieDog,0,0,12,0] becomes [Crow,0,0,13,0]
21A:0 (0x2768) [ZombieDog,2,0,12,0] becomes [Crow,0,0,13,0]
21A:1 (0x277E) [ZombieDog,2,0,12,0] becomes [Crow,0,0,13,0]
21A:2 (0x2794) [ZombieDog,2,0,12,0] becomes [Crow,0,0,13,0]
Created 206:0 (0x0) [ZombieDog,0,0,12,0] at (-16696,0,-8993)
Created 206:1 (0x0) [ZombieDog,0,0,12,0] at (-23846,0,-24114)
Created 204:1 (0x0) [Tyrant1,0,0,18,0] at (-1516,0,-14599)
Created 204:2 (0x0) [Tyrant1,0,0,18,0] at (-16826,0,-1381)
106:0 (0xE02) [ZombieGuy1,0,128,5,0] becomes [ZombieGirl,3,128,10,0]
106:1 (0xE18) [ZombieGirl,0,128,10,0] becomes [ZombieGirl,4,128,10,0]
106:0 (0xEB8) [ZombieGuy1,0,0,5,0] becomes [ZombieGirl,3,0,10,0]
700:0 (0x167E) [ZombieNaked,6,0,46,0] becomes [Crow,0,0,13,0]
700:1 (0x1694) [ZombieNaked,6,0,46,0] becomes [Crow,0,0,13,0]
700:2 (0x16AA) [ZombieNaked,6,0,46,0] becomes [Crow,0,0,13,0]
700:3 (0x16C0) [ZombieNaked,6,0,46,0] becomes [Crow,0,0,13,0]
700:4 (0x16D6) [ZombieNaked,6,0,46,0] becomes [Crow,0,0,13,0]
Created 508:0 (0x0) [ZombieDog,0,0,12,0] at (-14655,0,-25359)
Created 508:1 (0x0) [ZombieDog,0,0,12,0] at (-21197,0,-8899)
Created 606:0 (0x0) [Tyrant1,0,0,18,0] at (-8916,0,-20755)
Created 606:1 (0x0) [Tyrant1,0,0,18,0] at (-5730,0,-15721)
Created 401:0 (0x0) [ZombieGirl,2,0,10,0] at (-13754,0,-21677)
Created 401:1 (0x0) [ZombieGirl,0,0,10,0] at (-19745,0,-13819)
Created 401:2 (0x0) [ZombieGirl,3,0,10,0] at (-16082,0,-14155)
Created 401:3 (0x0) [ZombieGirl,0,0,10,0] at (-21149,0,-16983)
Created 401:4 (0x0) [ZombieGirl,0,0,10,0] at (-25359,0,-22462)
Created 401:5 (0x0) [ZombieGirl,3,0,10,0] at (-25122,0,-14988)
Created 302:0 (0x0) [ZombieArms,0,0,17,0] at (-16350,0,-6350)
Created 302:1 (0x0) [ZombieArms,0,0,17,0] at (-15593,0,-12206)
Created 302:2 (0x0) [ZombieArms,0,0,17,0] at (-15413,0,3233)
Created 108:0 (0x0) [Crow,0,0,13,0] at (-15038,0,-20903)
Created 108:1 (0x0) [Crow,0,0,13,0] at (-15672,0,-15479)
Created 108:2 (0x0) [Crow,0,0,13,0] at (-18932,0,-21283)
Created 108:3 (0x0) [Crow,0,0,13,0] at (-12133,0,-9899)
Created 108:4 (0x0) [Crow,0,0,13,0] at (-14857,0,-5301)
Created 108:5 (0x0) [Crow,0,0,13,0] at (-15937,0,-10834)

Created another seed, this time, with only Ivies and Zombies, but zombies at high, and Ivies at low:
R720-RG26-XXU7307Z1Y000V0H3100ZZZZZZZZZZZZXFZ
Randomizing enemies:
Created 10A:0 (0x0) [Ivy,0,0,19,0] at (-25669,0,-6991)
Created 10A:1 (0x0) [Ivy,0,0,19,0] at (-24601,0,-12326)
Created 60E:7 (0x0) [ZombieCop,0,0,1,0] at (-22957,-18000,-21240)
Created 60E:9 (0x0) [ZombieCop,3,0,1,0] at (-22788,-18000,-2812)
Created 60E:10 (0x0) [ZombieCop,0,0,1,0] at (-22795,-18000,-25825)
Created 501:0 (0x0) [Ivy,0,0,19,0] at (24801,0,-18885)
Created 501:1 (0x0) [Ivy,0,0,19,0] at (19300,0,-19317)
Created 110:0 (0x0) [ZombieBrad,4,0,1,0] at (-1243,-7200,-1531)
Created 110:1 (0x0) [ZombieBrad,0,0,1,0] at (-1524,-7200,11763)
Created 110:3 (0x0) [ZombieBrad,0,0,1,0] at (-25631,-7200,-15876)
Created 110:4 (0x0) [ZombieBrad,6,0,1,0] at (-25741,-7200,7116)
Created 110:5 (0x0) [ZombieBrad,0,0,1,0] at (-12840,-7200,11294)
Created 110:6 (0x0) [ZombieBrad,4,0,1,0] at (-26103,-7200,-23237)
Created 110:7 (0x0) [ZombieBrad,1,0,1,0] at (-22754,-7200,11689)
Created 110:8 (0x0) [ZombieBrad,0,0,1,0] at (-16184,-7200,9505)
Created 110:9 (0x0) [ZombieBrad,2,0,1,0] at (-3607,-7200,-7506)
Created 110:10 (0x0) [ZombieBrad,2,0,1,0] at (-2309,-7200,-15063)
Created 600:0 (0x0) [Ivy,0,0,19,0] at (-10507,-1800,-17217)
Created 600:1 (0x0) [Ivy,0,0,19,0] at (11117,0,-23144)
Created 60B:1 (0x0) [ZombieRandom,6,0,1,0] at (-9592,0,-24291)
Created 60B:2 (0x0) [ZombieRandom,6,0,1,0] at (-16267,0,-16673)
Created 60B:3 (0x0) [ZombieRandom,2,0,1,0] at (-22897,0,-11368)
Created 60F:0 (0x0) [Ivy,0,0,19,0] at (-20774,0,-20080)
Created 60F:1 (0x0) [Ivy,0,0,19,0] at (-13533,0,-23542)
Created 214:0 (0x0) [ZombieBrad,1,0,1,0] at (-15393,0,-11974)
Created 214:1 (0x0) [ZombieBrad,0,0,1,0] at (-13206,0,-13348)
Created 105:0 (0x0) [Ivy,0,0,19,0] at (357,0,-20588)
Created 105:1 (0x0) [Ivy,0,0,19,0] at (7250,0,-14836)
20E:2 (0x0) [LickerRed,0,0,14,0] becomes [ZombieCop,0,0,1,0]
20E:3 (0x0) [LickerRed,2,5,14,0] becomes [ZombieCop,0,0,1,0]
Created 613:0 (0x0) [Ivy,0,0,19,0] at (-17572,0,-19684)
Created 613:1 (0x0) [Ivy,0,0,19,0] at (-23644,0,-22869)
Created 104:0 (0x0) [ZombieGuy2,0,0,1,0] at (9665,0,-21224)
Created 104:1 (0x0) [ZombieGuy2,0,0,1,0] at (25984,0,-20554)
Created 104:2 (0x0) [ZombieGuy2,0,0,1,0] at (14410,0,-23028)
Created 104:3 (0x0) [ZombieGuy2,1,0,1,0] at (20073,0,-19639)
Created 104:4 (0x0) [ZombieGuy2,3,0,1,0] at (-11621,0,-24194)
Created 104:5 (0x0) [ZombieGuy2,4,0,1,0] at (21723,0,-25437)
Created 104:6 (0x0) [ZombieGuy2,1,0,1,0] at (4161,0,-18727)
Created 104:7 (0x0) [ZombieGuy2,0,0,1,0] at (-4955,0,-20918)
Created 203:0 (0x0) [Ivy,0,0,19,0] at (-26156,0,-21869)
Created 203:1 (0x0) [Ivy,0,0,19,0] at (-24000,0,-24031)
Created 304:0 (0x0) [ZombieScientist,0,0,1,0] at (-13942,0,-23085)
Created 304:1 (0x0) [ZombieScientist,1,0,1,0] at (-8629,0,-25486)
Created 304:2 (0x0) [ZombieScientist,4,0,1,0] at (-11839,-1800,-19444)
Created 304:3 (0x0) [ZombieScientist,2,0,1,0] at (-15996,0,-25686)
Created 304:4 (0x0) [ZombieScientist,4,0,1,0] at (-24125,-7200,-21846)
Created 210:0 (0x0) [Ivy,0,0,19,0] at (-20795,0,-15790)
Created 210:1 (0x0) [Ivy,0,0,19,0] at (-24771,0,-23991)
216:0 (0x0) [ZombieDog,0,0,12,0] becomes [ZombieCop,1,0,1,0]
216:1 (0x0) [ZombieDog,0,0,12,0] becomes [ZombieCop,3,0,1,0]
216:2 (0x0) [ZombieDog,2,0,12,0] becomes [ZombieCop,3,0,1,0]
216:3 (0x0) [ZombieDog,2,0,12,0] becomes [ZombieCop,0,0,1,0]
216:4 (0x0) [ZombieDog,2,0,12,0] becomes [ZombieCop,2,0,1,0]
Created 602:0 (0x0) [Ivy,0,0,19,0] at (-10822,0,-15937)
Created 602:1 (0x0) [Ivy,0,0,19,0] at (-14125,0,-1586)
Created 506:0 (0x0) [ZombieGuy2,4,0,1,0] at (-8572,-19800,-17259)
Created 506:1 (0x0) [ZombieGuy2,6,0,1,0] at (-3083,-14400,-22298)
Created 506:2 (0x0) [ZombieGuy2,6,0,1,0] at (-18381,-19800,-17829)
Created 506:3 (0x0) [ZombieGuy2,4,0,1,0] at (-21558,-19800,-13919)
Created 60C:0 (0x0) [ZombieGuy2,0,0,1,0] at (12671,0,-14466)
Created 60C:1 (0x0) [ZombieGuy2,1,0,1,0] at (10538,0,-23522)
Created 60C:2 (0x0) [ZombieGuy2,3,0,1,0] at (8825,0,-23327)
Created 60C:3 (0x0) [ZombieGuy2,6,0,1,0] at (22829,0,-11003)
Created 60C:4 (0x0) [ZombieGuy2,1,0,1,0] at (17393,0,-14752)
Created 213:0 (0x0) [Ivy,0,0,19,0] at (-13534,0,-19611)
Created 213:1 (0x0) [Ivy,0,0,19,0] at (-15418,0,-24063)
Created 209:0 (0x0) [ZombieNaked,4,0,46,0] at (-21411,0,-24506)
Created 209:1 (0x0) [ZombieNaked,2,0,46,0] at (-16935,0,-26162)
Created 209:2 (0x0) [ZombieNaked,2,0,46,0] at (-19387,0,-15562)
Created 30B:0 (0x0) [Ivy,0,0,19,0] at (-14556,0,-15473)
Created 30B:1 (0x0) [Ivy,0,0,19,0] at (-16866,0,-9218)
Created 502:0 (0x0) [ZombieGuy2,4,0,1,0] at (-15140,0,-25923)
Created 20A:0 (0x0) [Ivy,0,0,19,0] at (-9458,0,336)
Created 20A:1 (0x0) [Ivy,0,0,19,0] at (-14519,0,2786)
Created 109:1 (0x0) [ZombieScientist,3,0,1,0] at (-21099,0,-25509)
Created 109:2 (0x0) [ZombieScientist,2,0,1,0] at (-13904,0,-22167)
Created 109:3 (0x0) [ZombieScientist,0,0,1,0] at (-1878,0,-6054)
Created 109:4 (0x0) [ZombieScientist,0,0,1,0] at (-14803,0,-13427)
Created 111:0 (0x0) [Ivy,0,0,19,0] at (-25220,0,-24329)
Created 111:1 (0x0) [Ivy,0,0,19,0] at (-19900,-5400,-27500)
Created 205:1 (0x0) [ZombieGirl,2,0,10,0] at (-7235,0,-16722)
Created 205:2 (0x0) [ZombieGirl,0,0,10,0] at (-20302,0,-8713)
609:0 (0x0) [LickerGrey,0,0,51,0] becomes [Ivy,0,0,19,0]
609:1 (0x0) [LickerGrey,0,0,51,0] becomes [Ivy,0,0,19,0]
Created 20B:1 (0x0) [ZombieGirl,2,0,10,0] at (-24451,0,-26041)
Created 20B:2 (0x0) [ZombieGirl,4,0,10,0] at (-8377,0,-17003)
Created 20B:3 (0x0) [ZombieGirl,1,0,10,0] at (-17401,0,-18978)
Created 20B:4 (0x0) [ZombieGirl,1,0,10,0] at (-10113,0,-14217)
Created 20B:5 (0x0) [ZombieGirl,4,0,10,0] at (-14143,0,-25746)
Created 20B:6 (0x0) [ZombieGirl,3,0,10,0] at (-7559,0,-25294)
Created 20B:7 (0x0) [ZombieGirl,1,0,10,0] at (-22737,0,-15003)
Created 20B:8 (0x0) [ZombieGirl,4,0,10,0] at (-4889,0,-13748)
Created 20B:9 (0x0) [ZombieGirl,6,0,10,0] at (-14432,0,-14260)
Created 20B:10 (0x0) [ZombieGirl,4,0,10,0] at (-7221,0,-19841)
10B:0 (0x0) [LickerRed,17,64,14,0] becomes [Ivy,0,0,19,0]
10B:1 (0x0) [LickerRed,16,0,14,0] becomes [Ivy,0,0,19,0]
407:0 (0x788) [Spider,67,0,16,0] becomes [ZombieRandom,1,0,1,0]
407:1 (0x79E) [Spider,67,0,16,0] becomes [ZombieRandom,2,0,1,0]
Created 60D:1 (0x0) [Ivy,0,0,19,0] at (-25246,0,-23778)
Created 60D:2 (0x0) [Ivy,0,0,19,0] at (-18779,0,-15002)
Created 207:0 (0x0) [ZombieTestSubject,6,0,1,0] at (-24396,0,-21681)
Created 207:1 (0x0) [ZombieTestSubject,2,0,1,0] at (-25456,0,-24424)
Created 207:3 (0x0) [ZombieTestSubject,4,0,1,0] at (-24535,0,-12908)
Created 207:4 (0x0) [ZombieTestSubject,6,0,1,0] at (-25690,0,-10962)
Created 116:0 (0x0) [Ivy,0,0,19,0] at (-20772,0,-25169)
Created 116:1 (0x0) [Ivy,0,0,19,0] at (-23497,-7200,-22880)
405:0 (0xF9A) [ZombieGuy1,0,0,37,0] becomes [ZombieRandom,2,0,1,0]
405:1 (0xFB0) [ZombieGuy1,0,0,37,0] becomes [ZombieRandom,0,0,1,0]
405:2 (0xFC6) [ZombieGuy1,0,0,37,0] becomes [ZombieRandom,0,0,1,0]
405:0 (0xFE0) [ZombieGuy1,0,0,3,0] becomes [ZombieRandom,2,0,1,0]
405:1 (0xFF6) [ZombieGuy1,0,0,3,0] becomes [ZombieRandom,4,0,1,0]
405:2 (0x100C) [ZombieGuy1,0,0,3,0] becomes [ZombieRandom,4,0,1,0]
405:0 (0x1044) [ZombieGuy1,2,64,37,0] becomes [ZombieRandom,0,0,1,0]
405:1 (0x105A) [ZombieGuy1,4,64,37,0] becomes [ZombieRandom,6,0,1,0]
405:2 (0x1070) [ZombieGuy1,4,64,37,0] becomes [ZombieRandom,4,0,1,0]
405:0 (0x108A) [ZombieGuy1,2,64,3,0] becomes [ZombieRandom,1,0,1,0]
405:1 (0x10A0) [ZombieGuy1,4,64,3,0] becomes [ZombieRandom,4,0,1,0]
405:2 (0x10B6) [ZombieGuy1,4,64,3,0] becomes [ZombieRandom,2,0,1,0]
405:0 (0x10D4) [Spider,75,0,16,0] becomes [ZombieRandom,2,0,1,0]
405:1 (0x10EA) [Spider,67,0,16,0] becomes [ZombieRandom,6,0,1,0]
113:0 (0x10B4) [ZombieRandom,4,128,5,2] becomes [Ivy,0,0,19,0]
113:1 (0x10DC) [ZombieRandom,8,64,5,3] becomes [Ivy,0,0,19,0]
113:2 (0x10F2) [ZombieRandom,8,64,5,3] becomes [Ivy,0,0,19,0]
113:3 (0x1108) [ZombieRandom,8,64,6,3] becomes [Ivy,0,0,19,0]
113:4 (0x111E) [ZombieRandom,8,64,6,3] becomes [Ivy,0,0,19,0]
113:1 (0x114C) [ZombieRandom,6,0,5,3] becomes [Ivy,0,0,19,0]
113:2 (0x1162) [ZombieRandom,6,0,5,3] becomes [Ivy,0,0,19,0]
113:3 (0x1178) [ZombieRandom,0,0,6,3] becomes [Ivy,0,0,19,0]
113:4 (0x118E) [ZombieRandom,0,0,6,3] becomes [Ivy,0,0,19,0]
113:0 (0x123C) [ZombieRandom,4,128,5,2] becomes [Ivy,0,0,19,0]
113:1 (0x1264) [ZombieRandom,8,64,5,3] becomes [Ivy,0,0,19,0]
113:2 (0x127A) [ZombieRandom,8,64,5,3] becomes [Ivy,0,0,19,0]
113:3 (0x1290) [ZombieRandom,8,64,6,3] becomes [Ivy,0,0,19,0]
113:4 (0x12A6) [ZombieRandom,8,64,6,3] becomes [Ivy,0,0,19,0]
113:5 (0x12BC) [ZombieRandom,8,64,6,3] becomes [Ivy,0,0,19,0]
113:1 (0x12EA) [ZombieRandom,6,0,5,3] becomes [Ivy,0,0,19,0]
113:2 (0x1300) [ZombieRandom,6,0,5,3] becomes [Ivy,0,0,19,0]
113:3 (0x1316) [ZombieRandom,0,0,6,3] becomes [Ivy,0,0,19,0]
113:4 (0x132C) [ZombieRandom,0,0,6,3] becomes [Ivy,0,0,19,0]
113:5 (0x1342) [ZombieRandom,0,0,6,3] becomes [Ivy,0,0,19,0]
113:0 (0x2038) [LickerGrey,0,0,14,0] becomes [Ivy,0,0,19,0]
113:1 (0x204E) [LickerGrey,0,0,14,0] becomes [Ivy,0,0,19,0]
113:2 (0x2064) [LickerGrey,0,0,14,0] becomes [Ivy,0,0,19,0]
40D (0xF2C) opcode removed
Created 40D:0 (0x0) [ZombieRandom,3,0,1,0] at (-26092,-1058,-20300)
Created 40D:1 (0x0) [ZombieRandom,6,0,1,0] at (-20967,-1800,-25758)
Created 305:0 (0x0) [Ivy,0,0,19,0] at (-8134,-5400,-17864)
Created 305:1 (0x0) [Ivy,0,0,19,0] at (-26028,-5400,-19184)
Created 20F:0 (0x0) [ZombieGuy3,3,0,1,0] at (-25804,0,-3956)
Created 20F:1 (0x0) [ZombieGuy3,3,0,1,0] at (-17405,0,-25761)
Created 20F:2 (0x0) [ZombieGuy3,6,0,1,0] at (-18922,0,-5377)
Created 103:0 (0x0) [Ivy,0,0,19,0] at (20750,-5400,-19455)
60A:0 (0x12F8) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:1 (0x130E) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:2 (0x1324) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:3 (0x133A) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:4 (0x1350) [Vines,32,32,48,0] becomes [Vines,32,32,0,0]
60A:5 (0x1366) [Vines,0,32,48,0] becomes [Vines,0,32,0,0]
60A:0 (0x137E) [ZombieNaked,0,0,46,0] becomes [ZombieCop,4,0,1,0]
60A:1 (0x1394) [ZombieNaked,0,0,46,0] becomes [ZombieCop,0,0,1,0]
60A:2 (0x13AA) [ZombieNaked,6,0,46,0] becomes [ZombieCop,0,0,1,0]
Created 301:1 (0x0) [Ivy,0,0,19,0] at (-25465,0,-27700)
Created 301:2 (0x0) [Ivy,0,0,19,0] at (-21253,0,-19954)
Created 112:0 (0x0) [ZombieBrad,4,0,1,0] at (-12818,-5400,-12853)
Created 112:1 (0x0) [ZombieBrad,4,0,1,0] at (-17706,0,-18380)
Created 112:2 (0x0) [ZombieBrad,6,0,1,0] at (-14574,0,-13721)
Created 616:0 (0x0) [Ivy,0,0,19,0] at (-11569,0,-12403)
Created 616:1 (0x0) [Ivy,0,0,19,0] at (-11999,0,-25588)
Created 211:0 (0x0) [Ivy,0,0,19,0] at (9893,0,-14730)
Created 211:1 (0x0) [Ivy,0,0,19,0] at (-9260,0,-15296)
Created 10D:1 (0x0) [ZombieBrad,0,0,1,0] at (-25738,0,-14640)
Created 10D:2 (0x0) [ZombieBrad,2,0,1,0] at (-21191,0,-10632)
Created 402:0 (0x0) [Ivy,0,0,19,0] at (-17212,0,-6727)
Created 219:0 (0x0) [ZombieRandom,3,0,1,0] at (-168,0,-19759)
Created 605:0 (0x0) [ZombieGuy1,4,0,1,0] at (-12725,0,-21417)
Created 605:1 (0x0) [ZombieGuy1,0,0,1,0] at (-13858,0,-16119)
Created 605:2 (0x0) [ZombieGuy1,2,0,1,0] at (-8658,0,-15147)
Created 605:3 (0x0) [ZombieGuy1,0,0,1,0] at (-11885,0,-22778)
Created 605:4 (0x0) [ZombieGuy1,0,0,1,0] at (2168,0,-7378)
Created 605:5 (0x0) [ZombieGuy1,3,0,1,0] at (-4281,0,-8521)
Created 409:0 (0x0) [Ivy,0,0,19,0] at (-8631,-1800,13009)
Created 409:1 (0x0) [Ivy,0,0,19,0] at (8677,-7200,6156)
Created 215:0 (0x0) [ZombieScientist,6,0,1,0] at (-21397,0,-14511)
Created 215:1 (0x0) [ZombieScientist,6,0,1,0] at (-20857,0,-22146)
Created 215:2 (0x0) [ZombieScientist,6,0,1,0] at (-25887,0,-19397)
Created 215:3 (0x0) [ZombieScientist,0,0,1,0] at (-15808,0,-15020)
Created 615:0 (0x0) [Ivy,0,0,19,0] at (-6051,0,-17656)
Created 107:0 (0x0) [ZombieScientist,6,0,1,0] at (4321,0,-21996)
Created 107:1 (0x0) [ZombieScientist,1,0,1,0] at (-8492,0,-88)
Created 107:2 (0x0) [ZombieScientist,6,0,1,0] at (2788,0,-7427)
Created 107:3 (0x0) [ZombieScientist,0,0,1,0] at (4228,0,-13162)
Created 107:4 (0x0) [ZombieScientist,0,0,1,0] at (3973,0,140)
Created 610:0 (0x0) [Ivy,0,0,19,0] at (-17695,0,-23619)
Created 610:1 (0x0) [Ivy,0,0,19,0] at (-19561,0,-25278)
Created 20C:1 (0x0) [ZombieGuy1,0,0,1,0] at (-14914,0,-6867)
Created 20C:2 (0x0) [ZombieGuy1,0,0,1,0] at (-10797,0,-7891)
Created 20C:3 (0x0) [ZombieGuy1,4,0,1,0] at (-25923,0,-13961)
Created 20C:4 (0x0) [ZombieGuy1,0,0,1,0] at (-8377,0,-17003)
Created 20C:5 (0x0) [ZombieGuy1,4,0,1,0] at (-24943,0,-14247)
212 (0x8C2) opcode removed
Created 212:0 (0x0) [Ivy,0,0,19,0] at (-10597,0,-18845)
Created 10C:1 (0x0) [ZombieScientist,6,0,1,0] at (-17624,-3600,-16300)
Created 10C:2 (0x0) [ZombieScientist,1,0,1,0] at (-7951,-3600,-10812)
Created 10C:3 (0x0) [ZombieScientist,4,0,1,0] at (-24326,-3600,-10020)
Created 10C:4 (0x0) [ZombieScientist,2,0,1,0] at (-25374,-3600,-15452)
Created 10C:5 (0x0) [ZombieScientist,4,0,1,0] at (2426,-3600,-6980)
21A:0 (0x1B58) [ZombieDog,7,0,12,0] becomes [Ivy,0,0,19,0]
21A:1 (0x1B94) [ZombieDog,8,0,12,0] becomes [Ivy,0,0,19,0]
21A:1 (0x1BAE) [ZombieDog,7,0,12,0] becomes [Ivy,0,0,19,0]
21A:0 (0x1C1A) [ZombieDog,0,0,12,0] becomes [Ivy,0,0,19,0]
21A:1 (0x1C30) [ZombieDog,0,0,12,0] becomes [Ivy,0,0,19,0]
21A:0 (0x2768) [ZombieDog,2,0,12,0] becomes [Ivy,0,0,19,0]
21A:1 (0x277E) [ZombieDog,2,0,12,0] becomes [Ivy,0,0,19,0]
21A:2 (0x2794) [ZombieDog,2,0,12,0] becomes [Ivy,0,0,19,0]
Created 206:0 (0x0) [ZombieGirl,2,0,10,0] at (-25734,0,-18761)
Created 206:1 (0x0) [ZombieGirl,1,0,10,0] at (-23846,0,-24114)
Created 206:2 (0x0) [ZombieGirl,2,0,10,0] at (-22153,0,-8674)
Created 206:3 (0x0) [ZombieGirl,4,0,10,0] at (-21852,0,-15878)
Created 206:4 (0x0) [ZombieGirl,3,0,10,0] at (-16696,0,-8993)
Created 206:5 (0x0) [ZombieGirl,3,0,10,0] at (-21647,0,-8674)
Created 206:6 (0x0) [ZombieGirl,0,0,10,0] at (-26541,0,-9397)
Created 204:1 (0x0) [Ivy,0,0,19,0] at (-17121,0,-5990)
Created 204:2 (0x0) [Ivy,0,0,19,0] at (-16826,0,-1381)
106:0 (0xE02) [ZombieGuy1,0,128,5,0] becomes [ZombieScientist,2,128,1,0]
106:1 (0xE18) [ZombieGirl,0,128,10,0] becomes [ZombieScientist,1,128,1,0]
106:0 (0xEB8) [ZombieGuy1,0,0,5,0] becomes [ZombieScientist,1,0,1,0]
106:1 (0xECE) [ZombieGirl,0,0,10,0] becomes [ZombieScientist,4,0,1,0]
700:0 (0x167E) [ZombieNaked,6,0,46,0] becomes [ZombieTestSubject,3,0,1,0]
700:1 (0x1694) [ZombieNaked,6,0,46,0] becomes [ZombieTestSubject,1,0,1,0]
700:2 (0x16AA) [ZombieNaked,6,0,46,0] becomes [ZombieTestSubject,2,0,1,0]
700:3 (0x16C0) [ZombieNaked,6,0,46,0] becomes [ZombieTestSubject,0,0,1,0]
700:4 (0x16D6) [ZombieNaked,6,0,46,0] becomes [ZombieTestSubject,0,0,1,0]
Created 606:0 (0x0) [Ivy,0,0,19,0] at (2277,0,-8475)
Created 606:1 (0x0) [Ivy,0,0,19,0] at (5170,0,-23103)
Created 508:0 (0x0) [ZombieBrad,0,0,1,0] at (-14655,0,-25359)
Created 508:1 (0x0) [ZombieBrad,6,0,1,0] at (-21197,0,-8899)
Created 401:0 (0x0) [Ivy,0,0,19,0] at (-25359,0,-22462)
Created 302:0 (0x0) [ZombieNaked,0,0,46,0] at (-15413,0,3233)
Created 302:1 (0x0) [ZombieNaked,0,0,46,0] at (-15593,0,-12206)
Created 302:2 (0x0) [ZombieNaked,0,0,46,0] at (-16350,0,-6350)
Created 108:0 (0x0) [Ivy,0,0,19,0] at (-14857,0,-5301)
Created 108:1 (0x0) [Ivy,0,0,19,0] at (-15937,0,-10834)

See? Looks like its balanced regardless wich level you pick. It's looks like as I picked high for everyone so the randomizer consider every enemy has the same chances of being choosed


The big enum is not fully displayed in the body schema

Enum that does not fit into the display area is not displayed completely.

enum values or for that matter any other text like descriptions will get truncated if you use single line descriptions . You can

either click on the Multiline description top-right corner of schema box to show all the values
or use schema-description-expanded="true" option

single line view

here is multiline view


Yearn SDK instantiation error handling

When making many exits via exit-commit-tx on the DAI bonder, the bonder started responding with the following error. This did not cause any functional issues and the exit command continued to work. However, I believe this error should be better handled so that whatever effects happen downstream related to yearn don't break.
SdkError: HTTP to https://api.github.com/repos/yearn/yearn-assets/contents/icons/multichain-tokens/1 request failed (status 403 rate limit exceeded)
    at _callee$ (/usr/src/app/node_modules/@yfi/sdk/dist/sdk.cjs.development.js:2672:19)
    at tryCatch (/usr/src/app/node_modules/@yfi/sdk/dist/sdk.cjs.development.js:507:40)
    at Generator.invoke [as _invoke] (/usr/src/app/node_modules/@yfi/sdk/dist/sdk.cjs.development.js:737:22)
    at Generator.next (/usr/src/app/node_modules/@yfi/sdk/dist/sdk.cjs.development.js:562:21)
    at asyncGeneratorStep (/usr/src/app/node_modules/@yfi/sdk/dist/sdk.cjs.development.js:21:24)
    at _next (/usr/src/app/node_modules/@yfi/sdk/dist/sdk.cjs.development.js:43:9)
    at /usr/src/app/node_modules/@yfi/sdk/dist/sdk.cjs.development.js:50:7
    at new Promise (<anonymous>)
    at /usr/src/app/node_modules/@yfi/sdk/dist/sdk.cjs.development.js:39:12
    at handleHttpError (/usr/src/app/node_modules/@yfi/sdk/dist/sdk.cjs.development.js:2656:27) {
  error_type: 'sdk',
  error_code: undefined
}

This is known issue I reported a while back https://github.com/yearn/yearn-sdk/issues/236
but should be resolved now by updating sdk
Closed by https://github.com/hop-protocol/hop/commit/783655e57b23877a24f78c3b5b9d8441f6eb3bd3


Fix #5631: Call onError even when fallback is loaded

Remove return and remove pass of onError to the callback (avoid calling more than once)

Thanks a lot


Add a link to the HELICS GitHub repo in the README

Description
If merged this pull request will add a link back to the HELICS GitHub repository in the README. Just in case someone gets a tarball of the code and wants to know where it came from.
Proposed changes

Add a link back to the HELICS GitHub repo in the README

Small change, checking to see what's going on with the Homebrew error on the old XCode 8.3 Travis build.


Respect EDITOR environment variable

Currently, when opening a text file, Yazi just seems to try to use vim to open it. It would be great if instead it was referring to the EDITOR environment variable and use that value instead, with a fallback of vim if the variable is not set.

Sorry, I may not add it for the following reasons:

EDITOR seems to be a Unix-specific variable, that doesn't exist for Windows. (Yazi for Windows coming soon!)
You can use your own config file -- copy yazi.toml to ~/.config/yazi/yazi.toml, and modify the text opener as you like

Thanks for your quick reply, @sxyazi!
It pretty much seems like a very established standard on Unix systems, so it would be a pity if that didn't work. Couldn't we implement it as I suggested above, with using vim as a default if the EDITOR environment variable is not set? I think, by doing so, it wouldn't make a difference for Windows users but allow us to implement this de facto standard for Unix systems :smiley:

In fact, Yazi currently has support for it by simply modifying:
text = [
	{ exec = 'vim "$1"', block = true },
]

to:
text = [
	{ exec = '$EDITOR "$1"', block = true },
]

I can change it in the preset config, but it's unclear if this applies to all users.
Perhaps I could add it to the preset first, and make a conditional constraint in the following format later when the Windows version comes out:
text = [
	{ exec = '$EDITOR "$1"', block = true, for = "unix" }
]

That would be awesome! :rocket:


[webpack.cache.PackFileCacheStrategy/webpack.FileSystemInfo] Parsing of ... for build dependencies failed at 'import(configUrl.href)'.

This error is logged every time I navigate to a new page. It might not be logged if I am on a page using content? I am guessing that it is related to watching a page where velite is not used?
[webpack.cache.PackFileCacheStrategy/webpack.FileSystemInfo] Parsing of /home/spark/projects/nourish-run/nourish.run/node_modules/velite/dist/velite-hIhfoR9Z.js for build dependencies failed at 'import(configUrl.href)'.

repo

When the type in package.json is set to module, you should import velite by static import declaration:
import { build } from 'velite'

/** @type {import('next').NextConfig} */
export default {
  // othor next config here...
  webpack: config => {
    config.plugins.push(new VeliteWebpackPlugin())
    return config
  }
}

class VeliteWebpackPlugin {
  static started = false
  apply(/** @type {import('webpack').Compiler} */ compiler) {
    // executed three times in nextjs
    // twice for the server (nodejs / edge runtime) and once for the client
    compiler.hooks.beforeCompile.tap('VeliteWebpackPlugin', async () => {
      if (VeliteWebpackPlugin.started) return
      VeliteWebpackPlugin.started = true
      const dev = compiler.options.mode === 'development'
      await build({ watch: dev, clean: !dev })
    })
  }
}


Dynamic skies usda updates

Update sample scenes to use dynamic skies with accurate location settings as they are now working in USD Composer 2023.1.1 with Fabric Scene Delegate
New usda for upcoming dynamic skies tutorial

Looks great, thanks @r-veenstra

Denver is a bit shiny. Doesn't need to hold up the cesium-omniverse-samples release but worth addressing at some point, even if it means updating the glTF materials in the tileset.


Multimesh glitches

Operating system or device - Godot version:
windows, e8192d4
Issue description:
i can't even formulate the title, because i don't understand what causes this
i'm trying to create a field of tiles with multimesh, but it fails
i don't understand really whether multimesh just renders only a part of instances or transformations are applied in a wrong way.
Steps to reproduce:
open sample project

try running as is
try setting count to only "size" (not square size)
try changing Y coordinate from zero to one
try running several times

for me everytime it can display different results even without changing the code
Link to minimal example project:
https://www.dropbox.com/s/dsnm2r4bomv23gy/multimesh field.zip?dl=0

Hello, downloaded your sample and you have bug in your code. Version that works:
	for x in range(size):
		for y in range(size):
			print("(x*size)+y: ", (x*size)+y)
			var t = Transform(); # = mm.get_instance_transform((x*size)+y)
			mm.set_instance_transform((x*size)+y, t.translated(Vector3(x*cell_size, 0, y*cell_size)))


[AutoPR automation/resource-manager] Fix the runbook resource schema issues

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/4017

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/3125


Wrong Directory

Issue: There is no directory called proxy but after p press tab its completed to proxy
╭─mitesh at RestrictedArea in ~ using 15-04-30 - 15:12:40
╰─○ cd proxy
~bin
╭─mitesh at RestrictedArea in /bin using 15-04-30 - 15:12:50
╰─○ pwd
/bin
╭─mitesh at RestrictedArea in /bin using 15-04-30 - 15:12:55
╰─○

Tested on bash and default zsh its say
cd: no such file or directory: proxy

In this case, proxy is a named directory to the "home directory of the proxy user". If you run grep proxy /etc/password you'll see the home directory of the proxy user is /bin, probably.
This is because of the option cdablevars that is enabled, which allows to cd into "user directories" as well as named directories, which are variables that point to a directory. This means you can do cd user instead of cd ~user; or cd var instead of cd $var, where $var is a variable pointing to /some/directory (in absolute path form).
You can disable this behavior if you're not using it with unsetopt cdablevars, or you can also keep it enabled but not have those choices completed by running the following:
zstyle ':completion:*:complete:(cd|pushd):*' tag-order 'local-directories path-directories directory-stack' '*'

Whichever of those two commands you end up choosing, you can add it at the end of your zshrc file to set it up permanently.
Source: http://www.zsh.org/mla/users/2006/msg00776.html

Any updates? If it's solved please close


Keyboard hides drawer

Hello,
is there a way to change the position of the drawer when the keyboard appears ?
I have a search bar on the drawer and when I click in it, the keyboard covers the drawer.
This is my Code:
I would like to use the ".onTapGesture" to bring the drawer to the top position...

This is how it looks now.

Sorry, I'm still a noob with Swift and I am just learning it now. 🤓

I havent worked with Swift in a long time, but i think you can observe the keyboard and move the drawer up when the keyboard has appeared. Did something similar with another solution. ChatGPT might have a solution


⚠ Bofrost.be has degraded performance

In 21770e7, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1117 ms

Resolved: Bofrost.be performance has improved in 905b74c.