|
Post by spaar on Feb 11, 2015 20:08:40 GMT
Yeah, that'll be a problem. I've been getting by with just a simple loader for now, but that's probably mostly because I focus on adding things, not modifying them I can only think of a way to change these things at runtime, that won't really work with multiple mods modifying the same class. We might also want to use a common method for a console and an object explorer and things like that. I would imagine it could cause problems if every mod tried to add its own console Also: Why do you need to change something to use the chains ? That's just 'AddPiece.currentBlockType = 13;', right ?
|
|
|
Post by Zeblote on Feb 11, 2015 20:11:32 GMT
Yep, already edited that out. Was a little confused how that worked
|
|
|
Post by spaar on Feb 11, 2015 20:16:08 GMT
Ah, ok
|
|
|
Post by Zeblote on Feb 11, 2015 20:24:45 GMT
Regarding the object inspector and console, I've spent a fair bit of time on mine: Note: I'm on my phone. No idea if that just caused a massive pagestretch. Getting the editor gui skin was a real bitch, I ended up byte patching unity.exe so it would ignore the hide flags and allow me to export it to an asset bundle which I then included in my dll as an embedded resource. It's about 1.7MB due to the images. Tree view works, causes no fps issues with all 10k nodes expanded, but isn't realtime. Unity doesn't have callbacks for object creation (well, why would it) and the only way to refresh it is to call Resources.FindObjectsOfTypeAll<Transform> which I can't run every frame. Inspector is ugly, ignore pls until I get to fixing it. Console shows all Debug.Log messages, records stack traces for errors and colors them, same as the tree view doesn't cause lag with 100k messages recorded. The input field below it compiles UnityScript, you can see how I used it to move the starting block out of the way
|
|
|
Post by spaar on Feb 11, 2015 20:32:11 GMT
Oh, wow not sure what else to say, when I compare this to mine And I would never complain about the inspector looking ugly, since I don't even have one How often is the list updated then? I had the same problem, but I'm just doing a GameObject.FindObejctsOfTypeAll<GameObject> every frame, and then calling gameObject.FindComponentsOfType<Component> when it is expanded. I really shouldn't be doing that, but as long as I don't build any big machines it runs fine on my machine, so I just never got around to making somehting better Also, your console is really cool Having an input method that actually compiles and executes the code would be really useful sometimes I'm still kind of blown away by the whole thing Edit: Oh god, that's a lot of smiley faces
|
|
|
Post by Zeblote on Feb 11, 2015 20:42:57 GMT
How often is the list updated then? Every time you click on refresh. I had to do a lot of optimizations so it doesn't lag if you expand it all, basically what happens when you refresh the tree is it builds a structure of TreeNode instances that represent the object tree in the game. Then it goes through each node at the root level, checks the instance ID against a HashSet<int> of expanded node ids (I still can't believe how fast HashSet.Contains is) and adds nodes and if expanded their children to a List<TreeNode>. Those are the visible nodes. Then in each frame I can just calculate the starting and ending index in that list from the scroll position and draw the 20 rows you see. Of course if you expand/collapse a node the list of visible nodes has to be rebuilt, but that's pretty fast too. Only thing that really causes lag is the refresh button.
I'm calling Resources.FindObjectOfTypeAll<Transform> because I also want to get disabled objects and prefabs (seperate Assets tree for those)
|
|
|
Post by spaar on Feb 11, 2015 20:45:11 GMT
Oh, right. Sorry, didn't even notice the Refresh button.
|
|
|
Post by Zeblote on Feb 11, 2015 22:41:39 GMT
Actually, we might be able to hook the transform constructors/destructors/hierarchy changing methods and have a blazingly fast real-time tree view that way, much like the actual inspector in unity. Except they have the callback in native code of course.
|
|
SarahC
Builder
-Worried about the mod community-
Posts: 36
|
Post by SarahC on Feb 19, 2015 5:22:28 GMT
[wrong thread....!]
|
|
|
Post by SuburbanSB on Feb 19, 2015 5:43:45 GMT
Psst, SarahC this seems like the wrong thread to me...
|
|
SarahC
Builder
-Worried about the mod community-
Posts: 36
|
Post by SarahC on Feb 19, 2015 18:21:29 GMT
Psst, SarahC this seems like the wrong thread to me... Bugger, I thought it was the suggestions thread.
|
|
|
Post by disco on Feb 23, 2015 5:19:25 GMT
Hey.. I was giving a try to decompile the game and tweak the camera, but I'm having a bit of trouble right from the the beginning. When I use JustDecompile I get "JustDecompile only supports valid CLR assemblies" with game exe. What am I doing wrong? BTW, I have zero experience with Unity to be honest, but thats not the issue, for now...
|
|
|
Post by Zeblote on Feb 23, 2015 12:52:24 GMT
The game code is in besiege_data/managed/assembly_unityscript.dll and besiege_data/managed/assembly_csharp.dll, besiege.exe is just the native unity player
|
|
SarahC
Builder
-Worried about the mod community-
Posts: 36
|
Post by SarahC on Feb 24, 2015 5:14:50 GMT
The game code is in besiege_data/managed/assembly_unityscript.dll and besiege_data/managed/assembly_csharp.dll, besiege.exe is just the native unity player What?! Awesome! I thought it was closed source C++ in the .exe with a few DLL's in .Net added.
|
|
SarahC
Builder
-Worried about the mod community-
Posts: 36
|
Post by SarahC on Feb 24, 2015 5:23:48 GMT
I created a .Net CLR scanner a little while ago... code.google.com/p/dot-net-finder/Placing the .exe in Steam's "common" folder: C:\Program Files (x86)\Steam\steamapps\commonI ran this command line: DotNetFinder Besiege /S /Dbesiege\Besiege_Data\Managed\Assembly-CSharp-firstpass.dllbesiege\Besiege_Data\Managed\Assembly-CSharp.dllbesiege\Besiege_Data\Managed\Assembly-UnityScript-firstpass.dllbesiege\Besiege_Data\Managed\Assembly-UnityScript.dllbesiege\Besiege_Data\Managed\Boo.Lang.dllbesiege\Besiege_Data\Managed\Mono.Security.dllbesiege\Besiege_Data\Managed\mscorlib.dllbesiege\Besiege_Data\Managed\System.Core.dllbesiege\Besiege_Data\Managed\System.dllbesiege\Besiege_Data\Managed\System.Xml.dllbesiege\Besiege_Data\Managed\UnityEngine.dllbesiege\Besiege_Data\Managed\UnityScript.Lang.dll Folders checked: 16Files checked: 108C:\Program Files (x86)\Steam\steamapps\common>These are all the files that can be decompiled with Telerik - JustDecompile.
|
|