• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

[Miscellanous / Other] YARP, a sandbox map akin to RoTRP and SotDRP

Status
Not open for further replies.

~El

Level 17
Joined
Jun 13, 2016
Messages
556

Yet Another RolePlay (map)
An advanced WC3 sandbox map for RP

YARP is a WC3 sandbox map, designed for freeform RP. It is very similiar to maps like RoTRP and SotDRP, and, in-fact, strives to be a direct improvement upon them.

I started this project back in February 2016, after a build up of frustration from RoTRP and it's lack of a save/load system. As such, save/load capability has been probably the biggest motivator for me here, but I decided to improve on everything I could in the process.

It is still not entirely finished, and there is a slew of various things that still need to be added, fixed or polished before I can call the project done. I haven't really been working on it recently, and I am posting here in the hopes that someone will be interested in seeing this completed, or perhaps that someone will learn from it. The source code is open, hosted on the project's GitHub page. There is also a GitHub Wiki, containing various useful info about the map, a full listing of it's commands and a few tutorials. I'm not going to go into detail on how to compile everything together, but you need GMSI and JNGP, obviously.

I will attach the current compiled version of YARP if you want to take a look at it.

I am all open for suggestions, both regarding the map itself, or the wiki pages.

Feature Overview
Since YARP is meant to improve upon RoTRP, it supports most of it's commands in one form or another. You can find all commands available them on the project wiki.
There are, however, features exclusive to YARP. Off the top of my head:


  • Save/Load system (including terrain tiles and height adjustments).
  • Instantbuild. Allows buildings to be built the moment they are queued.
  • All doodads from WC3 RoC and TFT are available as buildings, totalling a little over a thousand different doods.
  • Advanced command system, with waits, aliases, macros, command splitting and other things. More on that here.
  • Advanced chat log.
  • Advanced camera controls (distance, angle of attack, field of view, rotation, roll, etc.)
  • Advanced rectangles/regions with atmospheric control.
  • Ability to remove terraindeforms (i.e. reset terrain height after using the height tool).
  • Animation loops are back! (with no S-bug)
  • Sequence (seq) command.
  • Neutral protection. Even if you hand your units over to neutral, other players can't claim them.
  • Instant load/unload on spawner.
  • Spawner teleports when casting abilities (prevents having to wait for the spawner to run around).
    There are probably other little things that I forgot.
Various video demonstrations.

 

Attachments

  • Yet Another RolePlay.w3x
    603.7 KB · Views: 580
Last edited:

~El

Level 17
Joined
Jun 13, 2016
Messages
556
You should be using this (or something similar) for your save and load system IMO.

http://www.hiveworkshop.com/threads/codeless-save-and-load-multiplayer.278664/

My biggest concern with this was that it wouldn't handle large payloads very well. I haven't tested myself, but from what I could gather, the sync rates aren't exactly great for a lot of data. Keep in mind, that the save/load system here has been designed for large amounts of units, anywhere from 50 to 1000 units per save.

In-fact, I think this is the reason why I decided not to use it:
Sync lib doc said:
4. Performance

It is fast. You are able to send about 1,000 integers, in a second or (usually) less in B.NET.

However it seems if you try to send more than 1,000 in a ~5 second timespan, the speed will start to slow down (significantly). This means you should not send more than 1,000 integers every 5 seconds or you will notice slower speeds. It is more than enough anyway. For example, sending 1k at map start could take ~0.3 seconds, but sending 1.4k could take almost 4 seconds. Also, to be clear, that is not the limit. You can send much more than a thousand at a time, but keeping it within that range will provide the fastest speeds.

I'm not saying that this system is bad, but I have my concerns over it's usability in the scenario that I need. I might try switching over in the future, but for now, this will do.
 
Status
Not open for further replies.
Top