Setmap will be disabled soon
 

The old setmap feature to connect levels will be removed in the next Graal version. Servers that still use it should switch to gmaps. I've seen that Delteria and N-Pulse still use it, hope it will not be a big problem.

The setminimap function will still work (although not required with gmaps).

Will it still work offline?

If he releases a new GraalEditor probobly not.

Well you can use loadmap or the gmaps file in the level editor for loading GMAPs anyway. There isn't really any reason to be using old maps these days.

There will not be a new editor yet. Converting setmap to gmap is normally quite easy, you can open an existing gmap to see where to put the level filenames.

Great...

Will this be the same Graal version with external windows?
Did you seriously expect him to be making a new Graal Editor? No, first he has decided to make a Universal version of Graal for Mac. He's also decided to make a level editor, a GANI editor, and a full-fledged RC client for Mac. I am very happy about his sudden change of heart [/sarcasm]

If you ask me, Stefan should just throw together some libs we can use to code our own new tools. I would be pleased.

There is no need, external scripting windows will soon be possible and I'm sure Stefan would want new tools created with GS2 so that those on Mac and other supported Systems could use them too.

Sneaky Stefan edit :O

Since he's not even scripting them I don't see a reason to halt external tools.
Scripted tools will never match external ones, external windows or not.

May I have your babies? I totally support that point. Tools shouldnt be part of the game itself, they should have their own executables or atleast be hardcoded.

Why can't they match the external versions?

If you are talking about an exact copy if the editor, coded in GScript...I dont see any problems with that. Fact is that such things dont exist though.

Well, there's tons of reasons that have been listed over the years.
If you're not scripting it, then there's no reason for there not to be a scripted editor. It won't steal any of your time away, order your slaves to get it done. I don't have a problem with it, just like the RC. I don't have a problem with the fact RC is scripted, it has its uses.
BUT, if you're not scripting these tools, so you no longer spend time on tools for Graal, why is it so hard to ask for the external tools to be updated? Its not like you'll be working double time scripting the internal tools and coding the external ones.
From my experiences with client-RC, I don't think internal tools will ever match the performance of external tools. They're sluggish, they carry the faults of the GUI interface, they reflect the performance of the client. Take for example... hmm, a gani editor(I assume this will be scripted as well?). Right now I can open up my gani editor and edit some gani's. It works full speed, no slow-down... its a simple application. But, I suspect, just like with RC, if I were to be using this as a tool in Graal, its performance would drop because Graal itself isn't that fast on my computer.

Also the fact that internal tools will never have the flexibility of external. It's programming vs interpreted. The tools will be as limited as the security and flexibility of GS2.
I mean, I do see the benefits of scripted tools... but personally for me they end up just being fail-safes. Like... "hmm, I'm not home so I won't bother installing the editor to edit this level, I'll just use the scripted one!" And that's about it. Scripted RC is a great accomplishment, and really pushes the limits of GS2... but as far as using it goes, I'll just stick to my external RC.

If you're not doing the scripting(and therefor, not dividing your time between scripting AND coding) why are you so determined to abandon tools that are basically there and just need to be updated?

The level editor and Graal Shop are basically just writing text files, I don't see the problem with giving us the source code for such programs.

Or maybe someone should just create their own using Python (which I recommend).

I was going to suggest a while back that someone, with adequate skill, should code an editor. However:

- What would Stefan and Unixmad think?

- How would you implement GS2 support?

- Wouldn't it be best if the editors became open-source so we can see the correct routines? That way, it'd be much easier.

I would much prefer having the source codes myself.

It'd be a decent challenge without but I guess we just want a level editor, not a challenge, that to some people could be near impossible.

Plus, it'd be nice to see some sort of open-source activity in this community, which steps beyond just scripting.

Sorry this has nothing to do with "setmap". The level editor is v2, we wont release the code for that. The scripted RC will replace the old RC in the near future, it's much easier to update and to improve and will also fix some several bugs with the current RC. The other tools will go the same way, probably first the level editor or an extension to the RCs npc-editor.
A big part of Graal is already open source, e.g. many scripts are available on the forums.

Well you did ask.
I'm sure it is easier... but it seems more like cutting corners. I'm sure there are tons of easier paths to take, but sometimes it's not always the best way to do it. I can't seem to find too many other people who agree with the tools going fully scripted, so how exactly is this going to help if no one agrees?

No, it doesn't. However, it does have something to do with the fact that you're disabling commands like setmap and neglecting the communities suggestions of an updated level editor.

Then if you won't release it, can't you update it to v4 standard?

Oh, this is the icing on the cake. As Dusty said, how will you compensate for poor game performance? Now it'll become a necessity to have perfect performance on the client to smoothly develop - which isn't good. I've always loved the fact how I can develop essentially lag-free where the client is completely laggy at peak times.

I'm sure this would just make things a lot harder for people like Tig, with his horrendous latency.

Also, why can't you just fix the bugs in the external RC?

Keeping everything contain in just on executable isn't such a good idea :/

Scripts, yeah. However, GScript is no where near as powerful as a real programming language.

It's quite clear that the majority, if not all, of the developers want updated external tools. Your biggest pitfall is you're just not LISTENING. We don't want "scripted tools with external windows", we want an updated external executable tools.

Surely, if you had the brains for business, you'd fulfill this obvious necessity in the development community - developers are currently your most important players, as it seems.

The idea for making the tools open-source was in response to your ultimate decision NOT to update external tools.

To sum things up, here are some major, MAJOR issues I have with this:

• It would be extremely laggy to develop.
• Newbies will have to pay to learn how to make levels, the same as it is with script.
• It's clear you're not listening to a word the community says
• The reason behind Graal's dwindling playercount is clear.

External tools are much more work, much harder to update, less customizable, always lag behind in number of features, and mean double or triple effort. By improving the scripted tools we can at the same time improve Graal drastically, e.g. the scripted playerlist which should make things quite interesting. If you are neglecting all that and still stick to the 80s/90s idea of offline stuff then I don't know how I can convince you anymore.

Please no, I beg you.

Edit: 80s/90s stuff? Excuse me? Last time I checked my developing tools didnt require a game to use them.

People are requesting a lot of stuff, and we must decide how we do the things with the best strategy. Doing the things we planned, we can do:
- make the tools work on all platforms
- make them customizable and easily updatable
- having them always up-to-date

There is a "downfall": you have to be online to script, you have to be online for modifying the game. But at the end this is an online game, you will need to chat with other people, you will need to watch documentation or code examples, you will need to test and debug the things you have worked on. All that requires online connectibility. So at the end that "downfall" can even be an advantage, because it forces people to speak and work together.

If you want to learn C++ then learn C++, but don't start speaking about the easyness of making platform independent tools or similar.

I'm already into C++, thanks. I know it costs work an time to do such stuff, but I dont know how you can stand this, too. I mean, you are also scripting stuff on Graal, right? Did you ever script with ScriptedRC? Its a pain in the ass, its just not cool :/

I'm all for online gaming. It's the future of gaming. Thought, development != gaming. Two different things completely.

Have you ever felt the difference between scripted RC and external RC?

Have you ever felt the difference between an OLE and the external level editor?

Don't you know what it'd be like if my internet goes down and I cannot develop, mainly because you've made it so?

I have no animosity towards you, Stefan but I have much animosity towards this whole idea of shifting towards a complete online, you-have-to-pay-to-develop idea. I don't think it's going to make you any money.

PS: The playerlist is completely different from scripted tools.

Having the above, I'm going to wait for the external windows to be implemented and see how things pan out. For scripted tools to be effective, they have to have exact or, if not, better functionality than the offline tools.

Stefan, perhaps you could tell us the speed difference between the external scripted windows and the external RC? Specifically when editing large (hundreds of lines) script files?

uh, i hate the internal rc for going fullscreen everytime i write
becuase alt+} -> fast enter = alt+enter = fullscreen xD

The scripted RC window is already faster for me now, the external RC often has problems when scrolling. The GuiMLTextCtrl can probably be optimized more though to only process the inserted text or the added text instead of parsing the whole text again when a modification has been made.

Alt is a control key, normally you need to use Alt-Gfx for aternative characters (whats fast enter)?

:cry::cry::cry::cry::cry:

Near future = one year or so
Some people here really take stuff too much to their heart >_<
Also the old RC doesn't even exist for Mac ? :confused:

Oh, thought you meant before my server became the best on Graal.
I guess we really just don't like the built-in tools. Perhaps if they were made faster/more convenient/etc. I suggested a while ago a plugin system for Graal, sort of like Firefox plugins, that work on all platforms, but outside of the Graal client so that they aren't affected by lag of the client, etc. Not sure how hard this is. Otherwise, please just add drag 'n drop to client-rc?
Nope, which is why I have to use software like VMware Fusion. When I want to use level editor, I have to boot into Boot Camp the lag is so bad.

Well Firefox plugins are not working on all platforms, they need to reprogrammed and repackaged for each platform. If you mean Firefox extensions, those are scripted :D
What do you mean with dragndrop, for scripting (?) or for file downloading? Normally it shoud already work for file uploading.

I'm sorry, I did mean Extensions. I use Safari, so haven't used Firefox for a while.

No, dragging and dropping for file browser does not seem to be working.

Also, I apologize for getting mad about RC.

Here's for everyone else: I have tried the external windows (testing ftw), and they work GREAT. A few bugs, but scripting is MUCH easier. Definitely it is fast enough to script.

I did not think it would be as good as it is, but it definitely is better than I thought. It is running very well ... taking very, very little of my CPU.

I'll report the bugs for it once I've had a bit more time to play with it -- no doubt I'll find some more.

But seriously, it is really not that bad at all.

I do believe that with a little work this could really replace the external RC.

o.o?

rawr

How? :(

I'd say he is a beta tester for the new Mac Universal client.