Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
@david-arthur, on Feb 28 2008, 04:54 AM, said in MissionComputer 4.0a5 now available:
As I thought. I happened to be testing it using a larger plug-in than usual yesterday, and experienced the same thing myself. The problem appears to be entirely with the graphical picker itself, taking too long to refresh, rather than anything specific to the PICT editor.
Why does it refresh the picker at all, if the pict hasn't been modified?
@desprez, on Mar 2 2008, 08:57 PM, said in MissionComputer 4.0a5 now available:
Oh, quick other question. I tend to save my graphics in 32 bit. MC automatically converts this to 16 bit for the rleD resource, right? I ask because my plug sizes are skyrocketing (22 ships = 15 megs!) and I wonder if it is because the graphics are the wrong bit size.
Just thought I'd mention: it's a good idea to dither your pics down to 16-bit before creating the RLE as MC can't dither them for you.
@guy, on Mar 6 2008, 11:49 PM, said in MissionComputer 4.0a5 now available:
Back when I implemented that code, a refresh was necessary for various reasons, and it didn't do as much harm, since the graphical picker didn't yet exist. Now, the refresh is unnecessary and undesirable, so today I modified the code to refresh only if the resource has changed.
As a side note, Ive finally traced the problems that were occurring with STR# and DITL/DLOG resources when MissionComputer ran natively on Intel. MissionComputer on Intel has to convert the numbers in resources into an Intel-native format (little-endian) in order to read/edit them, and then back into PowerPC/68K format (big-endian) when you save. For standard resource types like STR# and DITL/DLOG, though, it appears that the Mac OS tries to be helpful and automatically performs this conversion itself, meaning that when MissionComputer converted them a second time, they were back where they started, leaving unintelligible resources that confused the programme.
Ive now bypassed the second conversion for these resource types, and so should be able once again to provide a native Intel build with the next alpha.
@david-arthur, on Mar 8 2008, 08:59 AM, said in MissionComputer 4.0a5 now available:
For standard resource types like STR# and DITL/DLOG, though, it appears that the Mac OS tries to be helpful and automatically performs this conversion itself, meaning that when MissionComputer converted them a second time, they were back where they started, leaving unintelligible resources that confused the programme.
Ha ha, how curious. How did you determine this? Do you have an Intel machine now? In any case, looking forward to the next release
@guy, on Mar 7 2008, 03:52 PM, said in MissionComputer 4.0a5 now available:
How did you determine this? Do you have an Intel machine now?
Mostly through trial and error; I opened a STR#, and when it dropped into the debugger, looked at the various numbers it had loaded from the resource, and saw that they were 256 times too high, which is what happens when endianness is wrong. Since I knew I had converted the numbers properly and it worked perfectly for non-Apple resource types the only explanation was that the system itself was converting them. It does make sense, for compatibility reasons; there are still applications (even Intel-native ones) that use DITLs and STR#s, so in most cases the conversion would be helpful.
Yes, I'm now working on a new eight-core Mac Pro called Belgrave Road. Its main function is to allow for fantastically fast 3D renders, but one of the side benefits is to allow me to make MissionComputer (along with another EV-related application Im working on) Intel-native.
Awesome, good to hear
I've been poking at the link thing (problem with one way links and deleting and stuff). When you delete a link in the starmap MC doesn't update the resource unless you edit the system in another way, such as changing position or name.
So: Select system 189 -> Delete Link 189-190 -> Close starmap, it doesn't pay attention to the deleted link, there's a two way link between 189-190 Select system 189 -> Delete Link 189-190 -> Change something else about the system -> Close starmap, it deletes the link between 189 -> 190, but not 190 -> 189, unless you edit 190 after.
Hope this helps?
EDIT: Other than that? Everything works fantastically so far, keep up the great work! (Intel MacBook 1GB RAM, 2.13Ghz)
Several system editor suggestions for some point. Perhaps have double clicking create a system where you've clicked? Or a tool that allows you to do that. Secondly, the link tool is quite temperamental and hates me, sometimes not registering I've clicked on a system.
This post has been edited by Ephialtes : 10 March 2008 - 03:13 PM
@ephialtes, on Mar 10 2008, 04:04 PM, said in MissionComputer 4.0a5 now available:
When you delete a link in the starmap MC doesn't update the resource unless you edit the system in another way, such as changing position or name.
Ill take a look. There may be something wrong with the change-tracking.
Secondly, the link tool is quite temperamental and hates me, sometimes not registering I've clicked on a system.
Thats odd usually it errs on the side of selecting too many systems. Does zooming in or out make a difference?
@david-arthur, on Mar 10 2008, 09:18 PM, said in MissionComputer 4.0a5 now available:
That’s odd — usually it errs on the side of selecting too many systems. Does zooming in or out make a difference?
I can't reproduce it today. Maybe I was just missing when clicking, worry not. (I've been very tired the last few days ) Oh, and creating syst resources in a new plug tries to start at 129.
@ephialtes, on Mar 10 2008, 06:28 PM, said in MissionComputer 4.0a5 now available:
Oh, and creating syst resources in a new plug tries to start at 129.
Fixed, thanks.
Sorry for the 3 week grave dig, but what is the possibility that us Windows users will get to use MC? I've noticed a startling trend across the EVDC with reports that the newest version of Quicktime is crashing EVNEW when it tries to open PICT resources, and I'm worried that sometime in the future EVNEW may be rendered unusable by a software update. If that happens, the efforts of several plug-in developers, including mine, will be sent back into the stone age.
This post has been edited by JacaByte : 30 March 2008 - 12:10 PM
I don't know if you know this or not, but there are a number of tooltip / info box text strings that need updating. Off the top of my head:
There's probably a lot more. I have a feeling that you've already got a list of minor changes like this, but just in case you didn't...
This post has been edited by Desprez : 30 March 2008 - 01:08 PM
@jacabyte, on Mar 30 2008, 01:09 PM, said in MissionComputer 4.0a5 now available:
I've had a Windows version of MissionComputer for some years now; it's called 'Duessa', and there are ten points waiting for anyone who knows why. The trick is that it doesn't actually do anything useful. Somewhere around 3.2 it got as far as allowing you to open a file (the resource type weren't displayed correctly, and it crashed the moment you clicked on one), but most versions can't do much beyond displaying the about box, and I haven't tested it in a while.
Some of the longer-term work I'm doing for stability in the Macintosh version involves replacing the file-management core; the current version is based on the Macintosh Resource Manager, and so is the principal obstacle to a functional MissionComputer for Windows. The new core, called RFBlock, is mostly Windows-friendly, but I'm not sure yet whether it will be ready for inclusion in the 4.0 release. The really bad news with regard to your question, though, is that the main resource type I havent yet been able to handle in a Windows-friendly way is the PICT resource.
@desprez, on Mar 30 2008, 02:06 PM, said in MissionComputer 4.0a5 now available:
The graphic field in the weap resource incorrectly says 0-63 is the range, where the true range is 0-255.
Thanks I seem to have already fixed the oütf one in the course of other work, and the wëap one doesnt really matter since Im replacing that RDL script with a real wëap editor, but youre right that I should go through the help tags in the older editors in case there are any other surviving remnants from EV Override.
Oh yeah, and the BeamWidth field being fps for spinning weaps, isn't actually fps. It's really the delay between animation frames. (Tip is by the SpinContinuously flag in MiscFlags)
For the weap editor, how do you plan to deal with different guidance types in terms of the interface? Eg, for carried ship would you be disabling a lot of fields, changing field labels, switching to a new interface, or something like that?
@guy, on Mar 31 2008, 08:00 AM, said in MissionComputer 4.0a5 now available:
Mostly by changing labels and disabling/hiding fields as appropriate.
Okay, if you want to know exactly what fields and flags are applicable to different guidance types, check out my rezilla weap template. I went through and checked a lot of the stuff just to see what worked and what didn't so I'm pretty sure it's accurate. A couple of things of note:
Also, remember to mention negative inaccuracy/subtheta effects
@guy, on Mar 31 2008, 08:32 PM, said in MissionComputer 4.0a5 now available:
Okay, if you want to know exactly what fields and flags are applicable to different guidance types...
I've noted your comments, but keep in mind that my goal at present is to create a complete and functional editor for the wëap resource as specified, rather than to document the more obscure aspects of the game. Some things of this sort may be more appropriate to the page on weapons in the slowly growing help system rather than inclusion in the editor itself, where space is limited.
Right, just as a reference for what fields/flags to show, hide or change label of. Is the weap editor the last major feature planned for MC 4?
Are there plans for an editor to facilitate the placement of weapon exit points? This is truly painful to do by trial and error, and it's on the top of the list of things I miss from NovaTools.
@guy, on Mar 31 2008, 09:50 PM, said in MissionComputer 4.0a5 now available:
Is the weap editor the last major feature planned for MC 4?
I havent yet decided how many of the MissionComputer projects on which Im currently working will be part of the 4.0 release. The wëap editor is the only big editor Im working on at the moment, but there are at least a few smaller things that I want to get finished.
@desprez, on Mar 31 2008, 09:59 PM, said in MissionComputer 4.0a5 now available:
Are there plans for an editor to facilitate the placement of weapon exit points?
I havent yet begun designing a shän editor, so I cant comment on what its features would be.