RtC Suggestions

[Nestharus]

A long time ago I was planning on making a system that would be like OpenGL and would draw and render the objects in-game using JASS. In this way you could have full control of each model from fractioning off very specific pieces to shaving pieces of wood to deformations, collision detection, whatever.

Well, I think something like OpenGL that allowed people to do this would be a great feature to add into RtC. In this way people would have very small models we'll call particles for now (blocks normally) to build up the image. From here they can use textures to texture the different blocks, skeletons to place the blocks along, and whatever. From here we could do things like reflections, deformations (by changing the skeleton around or the block formations on the skeleton), fractions (spitting blocks off of the skeleton or breaking the skeleton up), and well, depending on how detailed it is, you could have things from breaking very small chips of stone off of a rock to full dust particle effects from moving around on the ground.

I think that this would be an incredible system to add into wc3.

Suggestion #2:
I know that you've already improved the game cache, but I think it still needs improvement. People need to create their own data structures in the game cache, so the game cache should take any amount of dimensions for data. Another possible idea would be to create something like hash tables for JASS and allow people to store entire tables into a single game cache entry and from there read the file and withdraw it (similar to PERL).

Suggestion #3:
Full 3D gridding capabilities. Currently, there are only rects (2D grids). I was going to create a system that allowed a player to define a 3D grid and place propeties within each cell of the grid. This would allow for radically detailed terrain by painting each cell wall and creating shadow walls (like angling the cell wall) to create terrain deformations. It would also allow players to create a skeleton for their environments (the grids) and well, add special properties, textures, and so on to the cells to create buildings, and I don't know what else. This would give people a whole new level of power for warcraft 3. Instead of creating a model and importing it into the map or whatever, people would just create textures used to wrap around different sized particle models (based on the level of detail you are going for). Warcraft 3 already this this built into it to a very small degree, but it's possible to enhance it a lot. I know that this will be pure JASS, but : ). From here, you can use these particles to create the shadow walls (walls that aren't really there, simple particles, and are based on the positioning of a cell's border) and whatever ; D. In essence, full dynamic terrain that can change in any way in real-time.

Object Data Structures:
I know that JASS newgen adds data structure into the language, but linking it up with various objects and so on requires people to design systems. It should really be built into Warcraft 3. Everything should be able to take a full data structure. I know you can use an in-game pointer to a data structure, but then we start getting into creating systems. Most of the time, when someone creates a system, they are creating something that should already be a part of the language.

Vector Forces:
This will enhance the graphics portion and allow people to manipulate their data structure based on the forces about. Just create something for collision detection and vectors (full 360 degrees). The rest can be done with a physics engine. I've seen systems for vectors, but these would be better as natives.


More of an extended math API:
Calculus 1 through 4? These would be very useful in something like the openGL expansion I mentioned above.

Networking:
Making a process to allow someone to host an instance of a map at a constant rate and keep it in the tray or something (not hosting through wc3). From here they can go play without disrupting their hosting. This would be pretty useful for keeping users connected even when the host is playing and loading up different maps. The map that's being hosted by the process will still be using functions and what not. Maybe even just creating an application to set up a server that doesn't use any JASS but just takes instructions and stores data. Maybe it's own script language or straight C++?

These are just some ideas : ).

Please tell me if I'm expecting too much : p. I know I can do all of this in JASS and some of it has alraedy been done in JASS, but custom natives would be *much* better.

Tell me what you guys think : D

Please feel free to reply with comments on what you think of these suggestions : )

 

[DSM]

sounds good to me. most of these ideas are going to be included in the map im makeing. verry well thawt of. altho i am going to be useing some advanced jass as well. you already know what kind of map im makeing and yes i want to ceap it under the cover untill we get done with the beta version to release. so only few people will know about it, but to make this map go faster and hopefuly get the beta out just so people can get a feal of whats comeing i could use moltiple pro jassers. we will begin on this project as soon as i reinstall my wc3.

Map Info

Name: (Not being Released Yet)

Description: (Not Being Released Yet)

Example of what beta is gona me:

Race for the beta: Human
Location/Senior: Human Empire, On the Edge of the kingdom in a small town

Discription: Ok i will release small discription on what the beta will have, aslo everything in the beta will most likely be put in the actual game!

You live in a small town just starting out. You have no job no home little money and little food. Get a job work your way to own a home, start a family, or by land and own a farm.

I dont want to give to much away just to ceap the suspence.

 

[SFilip]

First of all, thank you for your suggestions.

#1
While an interesting idea, this is highly unlikely to happen. If it, at any point, becomes possible to draw anything on screen, it will be an overlay on some screen coordinates - it's impossible for us to make something appear on the map itself (the way you create special effects, units etc). And even if that worked - Jass is simply too slow for 3D rendering, you would quickly reach op limit even when trying to do simple things.

#2
We neither improved gamecache nor we intend to. However, there will be several APIs that would work as replacements for the many (ab)uses gamecache has. As for data structures - there will be a BufferAPI which will allow you to easily write and read from one data stream thus allowing you to create not only data structures, but also much more.

#3
Having 3D equivalents for regions is an interesting idea, but I didn't quite catch from your explanation what exactly you expect from them. How did you intend us to texture those cells? What properties did you have in mind for cells? What were you referring to when you said WC3 already has it built in to a small degree?

> I've seen systems for vectors, but these would be better as natives.
Yes, one of the things on the TODO list is turning some of the stressful systems like the physics-related ones into natives (with the authors' permissions of course), but is currently not a priority.

> process to allow someone to host an instance of a map at a constant rate and keep it in the tray or something
Making an external/dedicated server was considered on several occasions, but turned out to be much harder than it seems. The server would have to account for things like pathing, unit AI, various game-related calculations (such as damage) etc. which is simply too much work in the end and would be used by a very small amount of people as it can't be made very flexible and user friendly.

 

[Nestharus]

#1:
It wouldn't actually draw the things on the screen. What would happen is instead of people making full models, people would make small block models. The natives would piece these blocks together to make full models. Also you can have skeletal frames (sets of 3D coordinates).

Example:

()-|-\/

 ()
-|-
/ \

This would allow people to manipulate the models in-game any way they liked and add a whole new level of realism to the game. From here, it can be designed so that only models that are visible to the player will be moving and animated. This is so that memory can be saved and so that the map runs more efficiently.

#2:
cool ;p

#3:
Current, there is a 3D grid for warcraft 3 that has limited z functionality. It's the regular wc3 grid. From here, players are allowed to make their own 2D grids (rectangles) and add them into dynamic grid systems (regions). However, this is as I said 2D. With regions, you can create any shape you want and so on, but once again 2D. It would be easy I suppose to add a 3D property to it, but I'm hoping for something a bit better.

Imagine a 3D grid that the player defines. Now, imagine they can activate and deactivate different cells in the grid to form the grid up. When a player initially defines a grid, that grid is completely empty. It has no cells, no definitions, etc. From here, a user defines a cell (length, width, height) and applies that to the grid. From here, that user defines the total grid size (simply initial size) x y z. After this, the user can add to the x, the y, or the z, and can even add to specific columns. Now, from here, the user can activate and deactivate cells within the grid. When a cell is active, that means it's a part of the grid. When a cell isn't active, that means it's still there, but it's not really a part of the grid and is ignored. Once a cell is defined, it can't be deleted. It can be cleared and re-written, but not deleted. When the cell is deactivated and cleared, the memory is cleared, but with the grid's definitions, the player can easily access that cell and write new properties into memory if that makes sense.

Now, imagine the walls of the cell. Remember that OpenGL extension I was talking about? Let's treat these walls as skeletons and paint 2D models over them. Now, we have a 2D wall (or 3D) that's painted over the cell's wall. Let's say it's painted over the south wall. Now, we want this to be in a different position. Any wall that's painted over a cell's wall has an origin at the cell wall, so with this we can offset the wall from the origin (move it up, down, left, right, up z, down z), we can angle it (angle it 30 degrees hori and 60 degrees vert) and do whatever we want. From here, we can define contours within the wall like wave effects (reposition the various small model blocks in the wall to create different effects). From here, we can also multi-layer the wall (let's say we create 10 layers of very thins blocks to make up the wall and only have those on the most outer layer showing. From here, let's say a player in-game chips the wall and knocks off 2 layers. The third layer would then show and it would only show in the part that was chipped). We can also use this to make our 2D textures into 3D textures (make the wall curve inwards, engraved with letters, w/e).

For 3D grids, a user would simply define an origin and then work off of that where only positive values can be attributed. They would access the grid cells through the grid's coordinates, not the WE coords (for example, if you wanted to get to the cell that's right 3 and up 3, you would just type 3,3 to access it). From here, you can create a new condition statement that checks if it's within a cell (grid name, x, y, z). You can also name grids etc.

Now, what else can someone use this for? Well, remember that icky terrain tile limit? Well, imagine using this to tile out your world =). You can use these small blocks to make various contour lines and so on. From here, users could make as detailed terrain as they wanted to make and add properties into the various particles of terrain. They could even have it snow and have the snow fall on to the dirt, turn dirt into mud, or whatever. With this extension and an OpenGL extension (remember to apply my meaning and not the literal meaning) users could realize any world that they wanted to make down to the pebble that's buried under 92 layers of sand (each layer being a tiny sand particle) at its most far left and 16 layers of sand at its most far right (this object would be planted in at an angle).

#4
You wouldn't have to do any syncing or anything in this. Let the map sync it up and do the networking. You also wouldn't have to do any of the unit AI. You would just have to relay information with a name. Let the map sync up the data and do all of that. I was going to do this, but I realized that running wc3 with a map that simply relays information would be kind of silly when all of that isn't needed. All it needs is the IP Addresses to send the information to, the data, and the names that way people can receive the information and have the maps update on their own. From here you can also check to make sure the information was received and do whatever. You don't have to account for pathing, unit AI, or any game related calculations. Let the maps do that. When they retrieve calculation, send that calculation to the other maps to ensure that everyone has the same calculation. You can also make a head map for things like damage calculation (the first player that connects or w/e, and when they leave go to the next player, etc).

I don't know, but that's all I was hoping for ; P. From here, you could make this server allow any player to host by hosting that player's game for them. All it does is relay information after all. The actual instructions would be in the map. Also, you could insert security protocols to protect a person's map, insert account and password information, and do all sorts of things. You could also allow players to define how their map should be hosted, meaning that maybe option 1 would be any player can create their own instance of the map, option 2 is the map is completely locked and can't have new instances of it created (it would be run 24/7 by the server, only one instance of it), option 3 might be that I don't know. You could get really creative with this. You could also make a base map that retrieves map instance listings from the server (it looks at instances of maps, looks at whether it's a 24/7 map or w/e, and also looks at whether that player has the map or not, and if they don't, a URL for where to download it that is of course located within the map (a string will be sent to the server that's associated with the map).

I was going to design something like the above for a war3 map that relayed information and sent that stuff to the players, but I'm sure that it would be much better if it were built into an application instead of a war3 map ;p.

Hope to hear from you soon : )

 

[SFilip]

#1
That would be extremely hard to maintain by the mapper and would end up unused by people, especially considering dummy units with locust can achieve the same results and are probably simpler to use than something we can make.
There's also the technical impossibility I mentioned earlier of us not being able to access the game's graphics engine in that way.

#3
As I said - we can't paint/render/texture anything, making this impossible.

#4
Wait, have you thought this idea through before posting? :S
It's no problem to make a simple packet relay program, in fact anyone with WinSock experience can do that easily. But you can't leave it on the clients to account for sensitive stuff like pathing and damage - that's not only desync-friendly, but also allows people to cheat in all kinds of ways without even having to download any 3rd party tool.

 

[Nestharus]

#1: Wouldn't be accessing the graphics, it would be accessing only models that are defined as particles (models made by modelers, not models in the game that are automatically broken up ^_^) and these models would be created like creating a unit and automatically updated and syncd with each other to form an actual thingie mibobber. It can be done in JASS, but I was thinking it'd be faster and better if it were done through natives =).

#3: It's not painting on to the cell wall. Once again it's creating units at those points along the cell walls using models created by modelers that are defined as particles (the models that you want to use). From here you can move it around by moving the unit (or the doodad or w/e). Once again, this system can be created in JASS, but again I was thinking it'd be better and faster in natives.

Now that you know those 2 are possible, would you want to add them in. It wouldn't actually be exactly like OpenGL, but the handling would be the same. It would just use nifty tricks and tips in the background to accomplish what can't be done normally ; ). Of course, the user would be responsible for providing the small particle models ;p.

#4:
Yes, I thought this through ^_^. If we had a head client (the first client to connect etc) that syncd up the maps, that would make it sync nicely, but... I agree with you on the cheats : p. However, considering some people do use custom combat systems (jass built combat systems with more power than the regular wc3 system) where the client's calculate out that damage, I don't really see any way around this, unless the server was loaded up with every system used by every map to make the calculations and what not. The problem here is making sure that all of the users are using the right map. If there was a way to check the map against the map that's supposed to be used, then it would prevent people from rigging out their maps, but again there are 3rd party program issues (sending packets to the main server with data that shouldn't be sent). But then again, anti-cheat things could be built into the map. When the user sends a packet to change their level into level 10,000 or w/e and the server accepts it and syncs up all of the clients, the instant the clients are syncd, we can have an anti-cheat system in the map I suppose that checks whether this is possible or not and checks previous events. But that would require storing all data in real-time (x, y, z coords, levels, all attributes, etc), and it would require storing various properties of the map (teleports, etc). From here, it can check the type of event that occured (a level), and see if the player did anything to make themselves level up, then check against the previous exp values and the experience or levels the thing gives, or if nothing happened reduce their level back to their original level, send the packet to the server, and have the server sync up all of the data.

I don't know, why not just give people the tool for relaying the packets and let them worry about security and syncing?

It's the same, give people the tool to create their own graphics in-game (keep in mind i'm not talking about regular OpenGL, I'm talking about creating doodads or w/e at specific points and piecing them together along a skeleton, only moving a single point and have the others constantly move to a set offset from that single point based on the skeleton), or the most detailed terrain imaginable. Whether or not people use these tools is up to them, but as long as they have them, that grants them new possibilities to do new things. I know for sure that I'd be interested in using these tools = ).

So, yes, the graphics are possible so long as you do them based on models that are labeled as particle effects and create the models using a regular function or a particle function. In fact, it might be good to create a new type of native called a particle or a block? And then manipulate those? ^_^

like call CreateParticle()

I don't know, you could get creative, but so long as you're creating them at points, it'll work. Also keep in mind to store these points in some sort of data structure/class in the background that the users can access through JASS and update =). This data structure will contain the data for the skeleton and the positions along the skeletons that the particles/blocks are on.

Oh well, I hope to hear you're reply now that you know what I mean by the graphics =). Yes, it'd be memory intensive, but that would be why you would remove the particles when the screen isn't on them and create them when the screen goes over them ;p. Having like 600 particles for a single unit and having 100 units scattered over the map might be intensive, but then again, only showing the outermost layer would be good too because then that 600 would reduce down to maybe 60, but that'd still be a lot and that'd be a really detailed unit ><. Having only the 30 units or w/e that are on the screen show instead of all 100 on the map would be better = )

 

[SFilip]

> would you want to add them in
No, at least not for now. It's too much work and would ultimately be too slow and too hard for practical use, i.e. only a few people would use it. There's a reason why models can be imported.

> If we had a head client (the first client to connect etc) that syncd up the maps
...then we would have no need for a simple relaying client - it would only make things slower in addition to making it harder for people to host.

> why not just give people the tool for relaying the packets and let them worry about security and syncing?
We simply don't want to release something that can have potentially disastrous results.

> remove the particles when the screen isn't on them and create them when the screen goes over them
Apart from that being extremely hard (read: impossible) to accomplish, it would put great strain on the CPU instead of memory which is actually worse.

 

[Nestharus]

>
Yes, I totally agree with you that it would be very difficult to use because you would have to use atleast trig to generate the skeletons in a fashionable manner to save up memory and so on and you'd have to use calc to to do the innsides of the things and what not. Let's say the user types in some coordinates and you aumatically generate a function or a set of functions that have those coordinates as their results to develope the shapes and what not. It would take a lot up and be slow because you would be keeping these things attatched though (constant timers and what not going off and constantly moving them to align with the core thingie). The more detailed it is, the more CPU power it would take up, the more memory it would take up, and well, the slower it would get over-all. To this point, 3-4 models on the screen might crash the entire machine depending on their level of detail. I knew this before I posted this message and well, i'm trying to figure out a way around this ;p. I still think this has great potential and would be a really incredible add-on for RtC : ). Also, something else that could be done with this is 3D graphical menus with all sorts of special effects and cool graphics : D.

>In a given game, sometimes not every client can host. The point is allowing everyone to be able to create a new instace of a map, even people who's ISPs have firewalls up to prevent this, ports closed to prevent this, or are just dumb. This would also give people an easy option to play while their computer hosts (can't have 2 instaces of wc3 running on the same computer), and it would allow options for players to make their maps be hosted 24/7 and lock their maps up so new instances cannot be created. 2 of these options would require a server that's up 24/7 for hosting the RtC network, and the other would just make it easier for people to host their own private instances on their own machines if they want to without having to have 2 machines (one for hosting wc3 and the other for playing it).

Please give this more thought. And the idea of syncing with the first player doesn't necessarily mean that player can host. The data is still going through the server. Ports are automatically openned to send communications back to the server when a server opens up communications with a user. A user cannot always open communications initially with another user because the ports aren't openned. I might have said that a little strangely, but RtC should focus on this for the networking:

Allow anyone to be able to create new instances of maps easily, even if they cannot host themselves

Give people who can host an easy way to host their own private instances of maps without having to have 2 computers (1 to play and 1 to host) because only one instance of wc3 can be running at a time.

When RtC is in it's final stages, have a server for hosting the RtC network with a relay application to give option 1 possibilities and give people possibilities for locking up their map to new instances, registering their map with the network, having their accounts on a network, and so on : ).

In essence, something like b.net but with more options and power and spiffy sex divas ;p.

>I agree, but if the particles are constantly being moved around etc, that would use up even more of the CPU's processing capabilities. Having them drawn out uses up memory and constantly updating them uses the CPU processes. Maybe don't remove them but when they come into view start to update them again? That wouldn't add any extra strain but remove the strain of constantly updating every model on the map instead of just the ones that are being shown. Another thing would be with the layer things to only update the things that show on the models (the outermost layers) and have the rest just lay there in invisible mode or something ;o. Really, I think it would be better just to remove and put backbecause you're going to have to move them or something when they become visible on screen or within the model itself. That's just what I think though : P.

So
#1:
I totally agree but I still think this has a lot of potential and would be really fantastic to have

#2:
I wholeheartedly disagree and believe that an application that went to the tray both for the server and for the users (only users who are creating new privatized instances and are hosting entirely on their own) would be an invaluable tool for the RtC network.

#3:
I heavily disagree because you would have more strain on the CPU constantly updating every particle in every model on every piece of the map. It would be better to only update them when they are in view (keep all of the particles attatched and moving around etc). Also, keep in mind bandwith. Just imagine the bandwith that would be used to update all of this. Things should only be syncd when a user comes in an area and needs to be updated on the area. Area updates should be stored in the server perhaps with maybe the machine that updated the area that way when another user enters that area the machine can send the data to the server and the server can send the data to the users entering. Just some interesting thoghts, but def not a final thought.

It would be better if every machine could just host though and would make things easier, but it has to be assumed that with the exception for private instances, no machine can host and has to depend on the server, or I guess the server could try to communicate with the machine and determine whether or not it can host and if it can it can treat it as a host and the user's machine could update the clients instead of the server in those cases where those machines have the updated information (user who needs updated information contacts the server, server sends the instruction to user 2 with the update, user 2 sends the update to user 1, user 1 sends the updated signal to the server like a big circle.) Once again, not a final thought but would be better.

I know I'm not very experienced with networking. I'm more of a programming guy that works on finding solutions to things that normally can't be done, so I'm sure you probably would have better ideas when it comes to networking.

Oh for the networking, maybe something like Ladder? Once again, I'm not very experienced with networking so I can't really say that I could argue this point, but I do know that it would be better if users worked off of a server in most cases instead of users working off of users =).

Oh well, I'll call this long essay #493491000419a.299f.299920014985f.392829D5.2



Btw, ty for taking your time to talk to me SFilip : )

 

[MindWorX]

I think the ideas aren't useful enough for Warcraft, but who knows, one things sure tho, we won't be implementing them anytime soon, but we'll consider it once we have all of RtC up and running again.

 

[Nestharus]

All righty : D

 

[redmarine]

These suggestions were all great but I fear that the WarCraft III engine is just too weak. The StarCraft II engine might be able to handle this well.

 

[Nestharus]

Uh, another thought for getting this to work on b.net. I know that it desyncs when people play together, but maybe just use warsoc for all of the networking? Have people host the game themselves where nobody else joins and then when the game starts up connect to other people? This would take away the single player features, but it could get RtC to be known on b.net before it made its jump to regular : ).

Just think of this as a promotion idea : P. Maybe have people host the map up for others to download, and then have those others go host the map themselves so they can connect to the actual game : ). Or host a map up describing what RtC does and is like and have that connect to a Demo Multiplayer game, something simple but fun that people would enjoy, like a DotA game or Footmen Wars game that utilizes the RtC natives.

This could connect to a central server thing with updates to RtC also. Let's say RtC is getting ready to make the jump to its own network so that single player features could be fully utilized, so the server's map could like send out the information to the players and they could go cool. : D.

What do you all think : P. *thinks he is full of cool ideas*

Another thing, for the OpenGL expansion, maybe make it for First Person View games only? This way models would be limited to a local area. Maybe even decrease the sight range. I know the OpenGL expansion can work on wc3 if people try >: (. I really want it in there : (. Or! Put it in and allow people to choose to use the expansion or to use set models :O. Or work the modelers to produce 49503094853094859043 animations and states for each model they produce using a set standard for animation types vrs animation indexes and model states vrs model indexes.
Example:
0- Stand Animation
1- Walk Animation
2- Run Animation
3+y to x- Attack y animation up to x
x + 1 - Stand on head animation
x + 2 - roll over and bark like a dog animation
x + 3 - bake muffins animation (and there better be a muffin tray! >: (
x + 4 - turn into a fairy (with glitter and everything)

Model States-
0- Regular State (form #1)
1- Next State (muffin cooking form with the try)
2- Next State (A Kamikaze Chicken)
3- Next State (Turn into a fairy)

Now, some of this can be programmed with the natives, IE you release a set of models, do the animations for them and so on, and change them into the various models in the models set using an index. Normally you can do model states and so on or whatever though, but that could be a work-around if you couldn't do that period.

So, what do you think of my kinky ideas blog #2? : D

 

[Cokemonkey11]

Nes I'll have to show you GHost++ tomorrow if you don't already know what it is, but I just thought of a good idea that sort of ties into yours.

If you guys here at RtC could modify GHost++ (it's open source) so that these "server hosting" players could host pickup games that check if joining players have RtC running before starting the game, you could easily implement B.Net into RtC.

Here's a model:
RtC server host starts GHost++ mod, logs into wc3 b.net, goes to same chat channel as bot.

host types .rtcPickup 5 [RTC]GAMENAME!!

host signs off and closes wc3, starts RtC and begins playing his map, which has directions for players to connect to.

Moments later players begin connecting to him.


~In the background~
RtC server host starts GHost++ mod, logs into wc3 b.net, goes to same chat channel as bot.
Simple enough, the player needs to be in the chat channel to use admin commands.

host types .rtcPickup 5 [RTC]GAMENAME!!
In the current version of GHost++, you can ".autohost <maximum#/games> <minimum#/players> <gamename>, but in this case 5 refers to maximum number of games, and [RTC]GAMENAME!! refers to the game name. the minimum number of plays variable is removed because these pickup games are only 1 player. It's just like starting a single player game, because once the game starts the bot leaves and goes back to the chat channel (it does this currently in ghost, which is the reason it can host multiple games at once)

host signs off and closes wc3, starts RtC and begins playing his map, which has directions for players to connect to.
Once the ghost mod is running, wc3 can simply be closed. it is connected and hosting constantly as long as its running or until an admin gives it the .unhost command. The player who has the winsoc target ip address hosts starts the map through RtC, which will soon have pickup games bring players into.

Moments later players begin connecting to him.
Huh? Here's what happened: The bot pinged the player 3 times to verify it's ping was less than x, then checked to verify it had RtC running, then started the game (which as you noted, connects to the IP address defined by the server). Because of the way GHost works, it can leave the game and if number of hosted games<5, it can immediately begin hosting another.


So really, whats the point?
-Hosting players have a very easy and seamless way of getting clients publicly
-GHost can take an unlimited number of cd keys as well as connect to PvPGN servers, allowing it to seamlessly get clients attention in many instances
-Done hosting? it's as easy as sending .unhost to the bot.

I'm curious to see what you think of my idea.

Also, if you've never heard of GHost you can check it out here:
forum.codelain.com - Index

Note the forum is shared by 3 different projects so just look at the category that says "GHost"

 

[SFilip]

Not possible.
GHost++ is made for battle.net. The whole idea behind WarSoc is not using the protocol wc3 normally uses. A program that hosts WarSoc maps would have to be made from scratch and it would be map-specific. If somebody at some point decides to waste a bunch of his time and develop it for his or some other map, that's cool, but we, the WarSoc team, are not going to develop any external hosting tool.

 

[Cokemonkey11]

Okay thanks for the reply, I mostly just thought it would be good since ghost is open source and I figured that meant easier for modders.

I hope someone out there decides to make an rtc hosting tool