I figured I'd change this thread into a thread of AGSEditor Plugin questions or requests, so they're not cluttering up the suggestion threads or repeated new threads posted. :)
Oops, I think I did forget to add access to Views to the API. I'll look into it.
Quote from: Pumaman on Fri 28/03/2008 18:04:43
Oops, I think I did forget to add access to Views to the API. I'll look into it.
I was wrong about my solution as I was looking at the contents of Game, not IGame, in the references viewer, but still got it to work as I hacked it a bit.. :)
I just casted IGame into Game to get at the ViewFolders. ;D I guess you're planning on adding that to the interface so it can be non-hacky :D anyway i got it working an have a pose previewer for each character. Yay! Screenies soon.
Thanks again!
lemmy
Hehe, ok cool. I'm going to modify the interface in the next version to add it, and also add a method to allow you to create new views.
That'd be awesmoe, thanks CJ! :D
One other thing, what is the control class you're using to display scaled sprites on forms?
PictureBox horribly filters the sprites when they are scaled, and any C# controls I find around the net are awfully slow drawing for animating on a timer. I'm assuming whatever class you're using I could grab from the AGS.Types namespace and place on my forms by placing a dummy panel and changing the variables in the designer code?
Otherwise I guess I'd have to write one myself (pah! such an un-windows programmingy thing to do! ;))
Thanks!
lemmy
The editor doens't use any controls for drawing the sprites, it does it manually using the OnPaint event. I could expose some sort of method to do this on the API -- in what way do you want to draw the sprite? Is it scaled but keeping aspect ratio, like the sprite manager and view preview do?
If so if I added some sort of method like this to the API:
DrawSprite(Graphics g, int spriteNumber, int x, int y, int width, int height)
would that provide the appropriate functionality that you'd need?
That would be awesmoe, thanks CJ! :D I can get the dimensions from the Image object to figure out the size to draw it at upscaled.
Thank you!
lemmy
Also what would be fab would be a similar interface to get at the room background graphics, and possibly even walkable areas. We're looking to add a room picture to the Teleport dialog wizard used by the AGX script so the user can select a target room and click the x, y, coords on the background itself.
Thanks again!
lemmy
Hi CJ! We've done a lot of work on the AGX integration. However along the way I've cheated a little and used a few things out of the AGS.Native namespace. I know this is a bit of a no no due to it being at risk of being refactoring etc, but we were eager to get it in for TFE development and I've also abstracted it all into another class so it would be easy to switch over.
The main change is a visual character placement tool. When you add a teleport, walkto, or pose change to the AGX script, it will display the target room and allow you to click/drag or nudge the character to their target position (Click for full image)
(http://www.cgempire.com/forgottenelement/AGXUpdateThumb.gif) (http://www.cgempire.com/forgottenelement/AGXUpdate.gif)
All characters present in the room according to the currently edited script will be displayed in their current pose and position, so you can align them up perfectly in cutscenes without ever having to edit X, Y coordinates. It can also display walkable areas to aid in placing your characters, and takes into account character scaling for walkable areas.
Obviously some of these are poking around where they shouldn't be, so I just thought I'd make you aware of what we're using, if any of it breaks in future versions it's obviously our own fault ;):
Native.GetAreaMaskPixel to get hold of the WalkableArea indices.
Native.LoadRoomFile to get hold of a loaded Room ptr needed to draw the background, and also to get access to WalkableAreas for scaling min / max values.
Native.DrawRoomBackground to actually draw the background.
That's all the functionality it uses, I think.
Thanks CJ! and apologies for poking about in lovely AGS's innards :o
lemmy
QuoteObviously some of these are poking around where they shouldn't be, so I just thought I'd make you aware of what we're using, if any of it breaks in future versions it's obviously our own fault
Yeah I'd strongly recommend against doing this. The main problem you'll find is that by accessing these methods directly you'll completely confuse the built-in room editor, and so if you have a room open and then switch tabs to your plugin, then later try and save or edit the room in its Room Editor pane, the editor will probably crash or corrupt the file.
There are also implications to you creating a second instance of the NativeMethods class, since it expects to be treated as a singleton.
If you need these methods for your plugin, I can implement them on the plugin interface in a safe and supported manner, which would also then be safe from breakages related to refactoring in future.
awesmoe stuff thanks loads CJ! :D
Hi CJ :)
Now we have the ability to create views programatically, another thing that would be amazingly useful would be the ability to import a sprite from a filename using the same behaviour that Quick Import Sprites uses, with the ability to replace existing sprites by passing a sprite number, as well as the ability to create Sprite Folders.
Thanks!
lemmy
Ok -- well I'll try to get the room mask stuff into the 3.0.1 Final, but any further requests will have to wait for 3.0.2. Feel free to make further posts in this thread if there's anything else that you find that you need.
Wow thanks CJ! :D Much appreciated!
Source Control and non-native stuff works a charm, thanks CJ! :)
One thing re: Source Control. I notice it adds the source control username into the Game.agf, and since this is under source control at the moment it doesn't seem to be possible to have multiple perforce users edit ags files at the same time without readding Game.agf to source control with their own username. Is there any way around this?
Thanks you lots!! :D
lemmy
Hmm, where in the XML is the username with perforce?
This is the source control data that gets saved when I'm using SourceSafe:
<Component Name="SourceControl">
<ProjectUnderControl>True</ProjectUnderControl>
<SourceControlPath>G:\vs\SRCSAFE</SourceControlPath>
<SourceControlProjectName>"$/testgame", SUCAAAAA</SourceControlProjectName>
</Component>
which doesn't seem to contain my username.
<Component Name="SourceControl">
<ProjectUnderControl>True</ProjectUnderControl>
<SourceControlPath>P4SCC#lemmy:1666##chris##lemmy</SourceControlPath>
<SourceControlProjectName>Perforce Project</SourceControlProjectName>
</Component>
Ahh I see, it's because I'm using Perforce :( the path contains the username (chris).
Ok I guess this is Perforce's fault then, sorry CJ.
lemmy
Hmm, well there must be a way around it because Perforce works with other applications like Visual Studio and they are able to be accessed by different users. I'll have to investigate this further.
Thanks again for the new editor plug-in goodies! :) Fantastic stuff! We now have completely automated view / sprite management for all our pose / gesture anims. :D:D
One other thing that would be really useful was some way to delete sprites. I thought about maybe just removing them from the Sprite Folder list but is this safe to do?
Ideally the most useful would be to tap into the "sprite is used in a view" check and be able to delete any sprites no longer used in a view in a folder, either recursively or explicitly in one sprite folder.
Any suggestions?
Thanks again for all of this! :)
lemmy
No, don't just remove it from the folder. If you do that, the reference will be removed but the sprite itself will not, and you'll end up with orphaned sprites that you can't access. And that would be bad :)
I'll look into adding some sort of DeleteSprite and GetSpriteUsage functions to the API.
Excellent! Thanks CJ! :)
I was wondering if you could grant access to DirectInput so people can make wrapper functions for input devices like gamepads?