I've recently started learning unity3d.
I'd like to procedurally generate some stuff (a forest made of tree prefabs) in the editor and then bake on the lighting. So the stuff needs to be instantiated before runtime.
This article was good for showing how to generate stuff before runtime
http://www.scriptocalypse.com/?p=102&cpage=1#comment-258
To summarize, it shows you how to add custom gameobjects to the gameobjects menu so you can instantiate them before runtime.
But you only get a menu option to click. I would like to be able to have more control of variables, so for instance set the radius, intensity and so on and then click a generate button. Any ideas?
I know I could do this by just changing the parameters in the script but a graphical interface like the way unity normally works would end up faster in the long run I think.
Ok, what I wanted was this
Allows you to design your own custom windows in the editor, unity is awesome!
Related
I am just starting out learning iOS development as a hobby in my spare time - so please be patient if this question seems dumb.
But how do I edit the UI without using the xcode graphical user interface? Is there some like underlying XML definition like Android has in android studio?
The reason I ask is if I ever need to change 1 dimension, it means I would have to manually go to every single storyboard element, and change it by hand as opposed to editing them efficiently from some main config file like dimens.xml
If you select your storyboard in Xcode, right click, and choose Open As -> Source Code, you will see the XML.
It's not simple to work with in that form (in my opinion), but it's available.
I'm developing an app on iOS 8, and using Xcode 6.
Being on iOS, to develop code you have to go through a Edit -> Compile -> Run -> Verify cycle.
A problem that I have had pretty much forever is: How do you keep this feedback loop as minimal as possible, regardless of how many levels of navigation your application has?
Consider this example. My application has say, 5 levels of navigation before I can get to the component I would like to develop. For instance:
Login screen -> Loading screen -> Menu w/ network requests -> Screen with input validation -> Text Editor
I want to iterate on my Text Editor component really quickly.
Due to the number of levels of navigation sequence looks like this.
Edit code.
Compile code.
Run app
(Login screen) Login (optional)
(Loading screen) Wait a while.
(Menu w/ network requests) Select an appropriate item
(Screen with input validation) Input data that passes validation
(Text Editor) Check that change to text editor has taken effect (e.g. change of font size or some such)
Of course, there are challenges in architecting the app to allow testing in this way, including but not limited to
how do you supply the view controller under test with test data?
how do you guarantee the view controller under test, tested in isolation, will look as expected when integrated back into the context of the app itself?
I'm convinced the answer is almost certainly NOT functional automated testing (KIF, Subliminal, Calabash et. al.), but some way of breaking the application up into testable units. Not from the perspective of unit testing, but of User Interface testing as well.
i.e. I should be able to tap 'Run' (Cmd + R) and immediately see the editor in action.
For quick iterations, I like to make an Xcode sub-project. To this by selecting the project file (the blue one), and then doing File->New... project. In the save window, select "Add to" to place it inside your project.
Then, just add your existing files by reference (make sure not to copy them!). They will build and run independently of the rest of the larger project.
This is especially useful for testing UI code where creating a functional interface is more difficult than processing the data it displays. You can mock up some simple objects to provide data for the UI, if needed.
You then do full integration and testing back in your main project.
I am considering diving into Kivy, but i have one question that is very important for my application:
is it possible to generate Kivy guis on the flight. I have seen the kv gui definition language, but in my use case a kivy app would download a gui (e.g. form) definition from a server and generate the gui/form on the flight (on the server the gui definition is also dynamically generated).
What would be the approach to implement this? For example is it possible to access and change the widget/layout tree that is normally generated from the kv definition?
Cheers, Lars
is it possible to generate Kivy guis on the flight
Yes, it is, and it's a very normal thing to do.
kv just lets you define a state of the widget tree, it doesn't set anything in stone. You can use add_widget or remove_widget at any time to change what widgets are displayed.
I'd like to know if it is possible to select a typeface, font size and be able to use it right away during runtime in an XNA application.
If it isn't possible using built-in runtime methods, maybe it's easier (or better, or faster) to do it using some automation software (like autoit) to create spritefont file in the background, and be able to use it afterwards in an XNA app without restarting the app?
I'm going to use this mainly on my own computer for testing and picking fonts, so I'm okay if it requires full VS installation along with XNA framework and any other stuff.
Easy put, it can be done, but you have to use WinForms, link to tutorial in order to load spritefonts. You could do it simpler, by making a couple of spritefonts before you do anything (or create spritefonts for every font you have and add them to the content). This is so, because of how XNA handles spritefonts. As you've seen, SpriteFonts are basically an xml file. This is not how the final binaries are. The final binaries are images containing every character in the font you selected at that size. That way, the gamer doesn't have to have the font installed in order to play your game, and therefore you can do some awesome stuff with fonts and the user can't use that font (unless he rips it).
I have not yet found a tutorial for winforms and spritefonts, but I suppose that the model version needs only a little modification for it to work with spritefonts.
(This might be better in the TestComplete forums, but I thought I'd give it a shot here anyway)
We are looking in to automated testing of our Delphi 2010 application with TestComplete. The main control that our application uses is our own custom control that derives directly from TCustomControl.
(For reference the control is like a digraming tool that display boxes with text in them. These boxes can be selected. the control is completely custom drawn, including the selection).
We are looking in to making this more TestComplete friendly so we can read data out of it (e.g. what data is loaded in to the control, what data is selected)
I should also mention that our application uses an MVC architecture and makes heavy use of interfaces. TestCompletes debug agent can't seem to return any type information about interfaces and thus we can't get any data from them. I suspect this is the root of our problem
I'm considering these two approaches:
Add new properties to the control that will return information about the currently selected box(es). e.g. text in the box, position on screen, hierarchical path, and access them via TestCompletes debug agent.
Look at creating a custom control add on for TestComplete (I'm not even sure you can do this with Delphi controls)
The problem with the first approach is the linker will often elimate properties and functions if they are not being used. We want to use our release build for testing not a debug build.
Does anyone have any advice on this or experience with this type of thing?
Thanks
Edit: I've just read the SDK help and custom control addons can only be created for .net and WPF controls.
You are right about the debug info - you can strip it out from the release build. Thus, you will test a release build and have access to internals at the same time.
A note regarding this situation: "the linker will often elimate properties and functions if they are not being used." You can cheat here to make the linker generate debug info for those funcitons:
Make the funcitons published. The linker does not touch published elements.
Make the funcitons virtual. The linker does not exclude virtual methods.
Call your functions somewhere in your code. To include the call in your code without actually calling anything, you can do something like this:
var t: Boolean;
begin
t := False;
if t = True then
TheFunctionThatNeverExecutes();
...
end;
You should reconsider your decision to use the release build for testing. The reason is that TestComplete needs some magic to make your testing life easier while you don't want this magic be present in the release build. So if you can elaborate on the reasons for not using a debug build for testing, we can try to find a solution to revoke this decision. The result may be that you will have access to all the relevant data of your control if you only reveal all available power of TestComplete.
Now back to the original question: You can overcome the interfaces problem by creating some special classes that wrap those interfaces and thus make the properties available in TestComplete.
Create a small (perhaps invisible) test form where you centralize access to instances of these classes. (Now the release mode link) Only create this form in debug mode so, when carefully designed, you only link in the relevant code when needed for testing.