Ryandor.com

Ok, so I am sitting here in the Altanta airport, pondering what native OS X application I want to write. Considering doing a UO tool, but not sure how useful that would be (unless of course I guess I decided to go ahead and do a native Mac OS X client).

I am open to doing native C/C++ backends, and only make the graphical user interface Obective C/Cocoa. I guess it depends on what it is to do. I have started a new UO library, and have it integrated with test stubs here on the Mac.

At any rate, time to wean myself off QT, and just commit to the Mac I guess. I guess if nothing comes to mind, I will just do the WorldMaker suite for the Mac. The hard decision, if one stays with UO, is what to do first:
1. Server
2. Client
3. Tools

Oh well, just rambling now anyway.

Flight got cancelled, so I am now settled in the Altanta Airport Hilton, until tomorrow.
Geesh, for the first time, I am open to idle chatter, and no one around. Perhaps I should have phrased it in Old English.

Eow meahte alswa wel.

_________________
Blog: http://www.sydius.org
Web: http://www.sydius.net

Make a statics#.mul patcher that works on any of the statics sizes

ditto!

I really dont understand what is being asked for here.

A way to edit the statics file? Just a patcher ( a way to take a "patch" file and patch to another?

Map making programs can create map2.mul, map3.mul, etc. any custom size you want. But no static patcher released can edit statics2.mul, statics3.mul, etc. They all only work with statics0.mul.

I am still very confused. For instance, WorldMaker map editor, edits any facet the user desires (and the associated statics files for that fact, to include dif files if that is selected).

MapGenerator also will generate any desires statics mul one is making (size wise).

But I don't think you are asking for an editor, but a "patcher". So what exactly are you looking for? What is the "source" and what is the output?

I don't want this, but I know many others do.. if MapGen already does it then ignore me

Let's say I create a custom map of Ilshenar. I use MapGen or whatever, it spits out map2.mul for me and (I'm guessing?) statics2.mul and staidx2.mul with the trees and coastlines and such in it.

Now I go in game and I build myself some towns and cities and dungeons and ruins and whatnot. What do I use to freeze those things to statics2.mul?

From what I understand, no such thing exists.

Ok, if you build in game, you are correct. That would of course be specific to any given emu (its worldsave format).

But if you built them in the multi editor, one could drag them into the map editor and save them.

I think I finally understand , so thank you for your patience.
The file format to use as the source would be a concern, given it would vary by emu.

From what I understand sphere and uox3 use a similar format, or if nothing else then sphere can use the .export command to save in the wsc file format that uox uses.

I've never seen a POL/RunUO worldsave so I'm not really sure what they use RunUO can freeze in game right? Does it work with statics2/3/4?

edit - V has made a custom statics patcher for Tragena that works with statics0.mul only, because we only use one map. I gave the source to a friend a few days ago who wants to try to rewrite it to work on statics2+ as well. So this request may be unnecessary as it'll be publically released if he can make it work with the 2nd/3rd/4th statics files. It would be Sphere save format if finished only though.

However, just in case he can't figure it out, or just in case it takes the next year, I do know there's quite a few shards dying for a patcher that'll work on Ilshenar and newer. Many in the sphere community at least, I'd assume the other emu users want the same as well

In the past, that was true. UOX3's worldfile format has changed since then though, it's split into multiple .wsc files amongst other things (and punt doesn't like it overly much . Though we do have a converter program that can convert from old to new & vice versa, it just needs a little updating to support all the necessary tags etc.

_________________
-= Ho Eyo He Hum =-

So true about disliking the UOX format. It is more then multiple wsc's by the way! The issue for me, is the format was not designed considering the use of an operator (again, my opinon). If it was not going to be easy for an operator to manipulate their data, then why make it text to begin with!
But in fairness to myself, I think I am the only one who actually wrote a tool outside the developers to actually do something with that world format! Just to ensure I wasn't prematuring judging it without at least validating for myself.

Ok, now that I am up on the story, suffice to say, static patchers are rather trival. But also, I wish people would reread the first post. This was, ok, what should be the first OS X (that is MAC) tool/project to do!!!!!!!

So I don't think a static patcher would probably be the first thing! Probably more likely an irc client, or a basic mul patcher.

Whoops I somehow missed the whole OS X part of that.

If you're going to do any UO tool for the mac, the first thing you'd want is a client I believe.. just because it's no good to develope on a computer if you cannot see your results

Well, I realized I could semi justify any of the three (client, server, tools) to myself, thus why I started wondering.

1. Server = Mac based pcs could run servers, so they could do shard hosting (and use the pc they probably had stashed around as their client).

2. Client = yes, Mac based machines could now play UO, but still not host shards.

3. Tools- the desire to host shards, quickly leads one to wanting to modify the data.

So I could see all of the three being needed, just not clear to me what is the "first" one!

I was leaning to a client being last, as I could take the time to ensure it would work with the server (if I decided I had to make compromises on compatablity due to my lack of skill, information, etc). But really hard to say, for me at least.

For a Mac project, it seems to me those 3 go together kind of in a tangled way.. each one relies on the other (or both others) to operate completly. So, my first thought is, get a solid design layout together.. figure out what each one will need from the other as much as possible.. (doubt i need to tell you though, punt)

anyways, with that figured out, i would start with the server, get a client actually connecting and both operating well together. Tools are tools.. those should start development once the foundation is set Server > Client > Tools (etc)

*shrugs*

_________________
Forget what you know, know what you forget.

I suppose one thing I am wondering is if anyone used the valley C++ mul libraries I did? I was in the process of a signficant rewrite, and they could be usable even for mac stuff. But if there really isn't any interest, I would just as well keep those Objective C as well.

punt, really... your talking as a professor, to the 3rd grade class.. only a few kids here know a bit over average, because they were held back from last year..

This is your hobby, honestly your the only guy i have ever even heard of seriously discussing UO related software on a MAC. I dont mean that negative, nothing against the MAC.. just my observation. Im sure there will be plenty that will love having ability to run UO related software on thier MAC, no doubt.. so if thats what you want to get busy with, hit it!

_________________
Forget what you know, know what you forget.

If you decide to take on a Mac project, you should go with a Client first. There's no real reason to do utilities for the Mac for a game that can't be played on a Mac. However, a Mac client could be beneficial. And some of that code might be transportable to a Windows client if you decided later on that writing the client was interesting enough to warrant doing a port.

On the Valley DLL, I'd like to use it but I've found it hard to get started, Here's a few things that I think would help.

1. Easier access to the compiled DLL.

2. A few simple example projects.

3. Documentation.

3. A support forum over at your site.

_________________
-= HellRazor =-
Shattered Sosaria is coming!
http://www.shatteredsosaria.com

damn, forgot we actually did have a 5th grade kid in here.. great...
*prepares his lunch money in advanced for HellRazor*

_________________
Forget what you know, know what you forget.

_________________
-= HellRazor =-
Shattered Sosaria is coming!
http://www.shatteredsosaria.com

Hmm, but many emu servers support linux, and they can't play UO natively on it. I linked tools to the concept that any one running a shard would want to have tools to modify the data. But I think I get the point!





Ok, step 1 is easy enough to take care of.
Hmm, step 2 and 3 get far harder (I am really bad at documentation).
But ok, I will continue on the rewrite of valley, to ensure it is just native C++ (and platform agnostic). It will be targeted for gcc, but that is mainly as I no longer keep msvc on my platforms. So I would of course love help if anyone is interested in testing and helping address the msvc issues (the only one I can think of is the need to define the hash_map).

Hey punt do you really so much like MAC? I dont think you should waste time on UO MAc client , after some time Osi will do it themselfs ,
I think you should better make a Anim Editor or something with anim, cuse that is one of the things what ussualy is not remade

From a development standpoint, yes, I do really like the Mac. I find it actually enjoyable to code and develop in.

At this point, as mature as the UO emu stuff is, looking for development fun makes a lot of sense. Plus, one really doesn't know how much UO Mac software may be appreciated, as there hasn't been any to date!

But at the moment, I am working on an updated Transition Editor, and then a refined MapGenerator update. Both that will be windows friendly *grin*

My brain go "OWWEE!"

Me sleeping now...*finishes his pint of milk*

Dev

_________________
"So...if crazy people don't know their crazy...does that mean your only sane if your know your crazy?"