Gauntlet Warriors :: View topic - MapData (in progress...)

Gauntlet Warriors https://gauntletwarriors.com/Forums/

MapData (in progress...) https://gauntletwarriors.com/Forums/viewtopic.php?f=54&t=500	Page 1 of 3

Author:	*nOsWildcard** [ Tue Jan 14, 2014 10:49 am ]
Post subject:	MapData (in progress...)
Project Status: Codding In Progress Build: 6 - 1/14/2012 - Finally! I'm free! No personal events to sidetrack me other than the inconvenience of my incredibly dull day job. Anyhow, I'm finally writing code I got around 6 builds I have tested so far and several different objects I have codded. This mod will be a lot more complex than the current MapData mod we use but this mod will be very flexible and will seem to have no perceivable limitations. So far if you want numbers there is a limit of 1,000 groups and each of those groups can have 1,000 monster/weapons/ammo/decorations/anythings in them and well take 1,000 and multiply it by 1,000 and you get One Million which is just INSANE. So I have decided not to increase the limits (which I totally could do I believe) any further than 1,000x1,000 due to the fact the potential is already BATSHIT INSANE. That being said at the moment of typing this I'm looking at my MD_SpawnWatch script which will be responsible for managing a list of new objects our future map editors will add to the maps. Basically anything new spawned with the name tag "Fabricated" will be added to this list and when the time comes the map editors decide to save it will store this list contents in the current group they are working on which will actually be kind of a kickass efficiency bonus because there is no need to use the horrendous AllActors iterator which literally looks thru every actor in the map that exists including ones not spawned by the player, the players themselves and the actor calling it will iterate thru itself too probably which is total bullshit so that's nice that MD_SpawnWatch will put together an easy list of shit to save

Author:	*nOsRurik** [ Wed Jan 15, 2014 11:12 am ]
Post subject:	Re: MapData (in progress...)
Wow, awesome!

Author:	*nOsWildcard** [ Wed Jan 15, 2014 2:54 pm ]
Post subject:	Re: MapData (in progress...)
- 1/15/2012 - Lots of planned functionality got codded today! I've codded the necessary functions needed to actually start recording the map data to the .ini file. Groups can be created and have actors stored under them however my concern is how naming is going to work in any kind of interface for map editing. I want to avoid problems such as multiple groups having the same name and groups with illegal names. I have codded a handy function that will assist in addressing part of this challenge which is a function that turns any string of text into a legal name that starts of with letters and only contains letters numbers and the underscore_symbol. The other part I think I'll address thru design which is having an internal reference name that is unique like: SkaarjWave_oC79Ly6T and never a problem and a human friendly name we can identify like: Skaarj Wave. A future problem could be how a group will be looked up for if you wanted to delete a group or select it which may be a challenge if you have multiple groups with the same name. Either something would have to be provided thru the interface to select which group or just simply not allowing groups with the same name to avoid bad confusing map editing practices anyways. I will be spending time on refining the code I have written today in the sense of fixing any bugs and also determining a more long-term design in how all these objects I have codded work together to store the entire contents of a map. The potential is great and the limits are unknown for this project. As I continue developing this further It will only get more and more powerful. I may have the minimum amount of framework already to have MD_SpawnWatch save a list of actors added to a map under a group. I can't wait to work on spawn control when I get to that part. It will be very exciting to have control over when and if groups spawn making for the most dynamic monster siege gameplay we have ever seen.

Author:	cadaverjuice [ Thu Jan 16, 2014 6:05 pm ]
Post subject:	Re: MapData (in progress...)
Mind=spinning

Author:	*nOsWildcard** [ Mon Jan 27, 2014 1:35 pm ]
Post subject:	Re: MapData (in progress...)
- 1/27/2013 - Build 70 It's been many days since I worked on this project, Lost focus on this project with the issues and challenges that have arisen from this new "Silhouette" system I'm creating. What is this Silhouette thing I'm working on you ask? What it does is when our map editors use the fabricator to spawn an actor in the map it swaps out the real actor with something I call in the code a "Silhouette" which is a decoration that looks exactly like the real actor it replaced in appearance and "feels" like the real actor it replaced as far as collision radius and collision height so it's the same size as well. Basically when our map editors are adding monsters to a map they are not really adding the real thing but instead statues that represent the real thing. This will prevent the monsters from wandering seeing new players who join the server or interacting with each other or anything else because they are not really monsters but just statues based of the real thing. When the game is played for real of coarse the real monsters and actors are spawned in the map and not the statue "Silhouette" of it. Silhouettes will be a helpful map editing tool that should make the process more smooth with less accidents that come with having live monsters in map. The Silhouette feature has presented many challenges to me and it is still not complete but I feel I have made good progress today and also have discovered the solution to one of the biggest problems behind Silhouettes. The biggest problem I had was placement of the Silhouette. Using the fabricator you could have multiple Silhouettes inside each other which is a huge problem when it comes to mapping because you cannot have multiple "anythings" for the most part occupying one space! In order to stop the problem that allowed Silhouettes to be spawned inside Silhouettes I had to code a check that would see if anything else was in the area and then decided if the new Silhouette the player wanted to spawn fit in that area or not. Easier said than done. I had many problems where it would flat out ignore all the collisions or had wrongly sized collisions and weird instances of the MD_SpawnWatch actor which is responsible for replacing fabricated actors with Silhouettes just disappearing for no damn reason whatsoever. I finally got it right however and I think I can make this system work. The system is not aesthetically perfect for you can tell the difference between real monsters and Silhouetted monsters because the Silhouettes don't copy the animations of the actors their based off of...yet. However the animation part of the Silhouette system is not the focus here it's the functionality and it has gotten a great boost today and I can see this concept coming to life now so at this moment I may be able to move on to more important parts of the MapData mod. Next I plan on working on the MD_Actor object which is a low level object that stores a single actor in the map data. MD_Actor objects are codded to store an actor's class, location rotation and if it has any additional properties it will store a reference to a MD_PropertyList object which contains a list of any changed properties about that actor. Aside from their design in storage in game they are going to need to store a reference to the instance of the actor they are binded to in game or a Silhouette when the map data is being edited. The plan is the MD_Actor objects are stored in a list in the MD_Group object and when the time comes it be map editing or the start of a game the MD_Group will make the MD_Actor object and the MD_Actor object will create the actor it has stored and set it's properties from the MD_Actor's MD_PropertyList object it may have. Over all, once I have an MD_Actor object for every actor placed in a map then at that point I can actually capture all that data and save it. As far as design is concerned I got to make a group switching system that can switch groups for newly added MD_Actor objects to be stored in. I got to make it so that each player adds an actor to their own currently selected group to prevent confusion when mapping when someone changes the group and suddenly everyone is adding their monsters to another players group! That'll be addressed in the design portion of this. UNRELATED DISCOVERY! I found out a hack that would allow the destruction and creation of Spawn Points! This is GREAT NEWS! Now I can give the power of this hack to our editors to destroy the lousy Spawn Points in a map and allow them to designate new ones!

Author:	cadaverjuice [ Mon Jan 27, 2014 6:28 pm ]
Post subject:	Re: MapData (in progress...)
New spawn points = boneriffic!

Author:	*nOsWildcard** [ Wed Jan 29, 2014 1:57 pm ]
Post subject:	Re: MapData (in progress...)
- 1/29/2013 - Build: 89 Not a huge amount of work got done today but definitely some important work. The codding I did today will setup for some significant progress to come next time I work on this. In detail last I discussed working with groups and having map editors add actors to their individually selected group. Challenge that comes with setting that up is that when an actor is spawned then in order for MD_SpawnWatch to register it with the right group MD_SpawnWatch will need to know the map editor in game who created it with the fabricator. Before today I've changed the fabricator a bit and added a new class to the fabricator called FabricationAlert. Whenever a player uses the fabricator to spawn an actor it spawns a FabricationAlert actor with it as well which self-destructs. The purpose of this FabricationAlert actor is for it to be found by MD_SpawnWatch and once MD_SpawnWatch finds the FabricationAlert it pulls the information stored in it. FabricationAlert stores a reference to the actor the map editor spawned and also a reference to the map editor who spawned the actor. FabricationAlert also has a dumb Boolean variable named ThisWasFabricated which is set to true before the FabricationAlert actor gets spawned. The reason I have the ThisWasFabricated variable is because simply nothing else in UT has that variable name! To explain further MD_SpawnWatch is a descendent of SpawnNotify which has a function that is called every time any actor spawns. The only thing stopping MD_SpawnWatch from registering every damn thing that spawns in a group is first it checks to see if the ThisWasFabricated variable exists and that's done by a handy function called GetPropertyText("ThisWasFabricated") which will return a blank string "" if that property doesn't exist which casted to a bool makes "" into false so everything besides FabricationAlert is ignored because GetPropertyText("ThisWasFabricated") is not true. Anyhow, what exactly does that do? To put it simple, It allows MD_SpawnWatch to tell if the actor was actually placed in the map by a Fabricator or not. Things spawn all the time in UT more often then you may think so having this check is important. The challenge I had in setting up this system is handing this information to MD_SpawnWatch from the Fabrication alert actor. In order to assign the values to FabricationAlerts variables such as What just spawned? Who spawned it? and ThisWasFabricated it had to spawn the FabricationAlert actor first and the problem with that is at the moment the FabricationAlert actor is spawned MD_SpawnWatch IMEDIATELY asks it for the value to those variables mentioned which are all blank of coarse because there is no time to assign it which will happen AFTER the damn thing actually spawned so yeah an obnoxious timing issue. I fixed this using static functions which allowed me to assign some values to the FabricationAlert before actually spawning it. I could go on and explain how static functions are different from regular function and how I assigned default.variables rather than instance variables but this already has become way more of a TL;DR then I intended to. A summary of this is that MD_SpawnWatch can detect actors added by map editors and know what it was they added and who added it to the map. From there I can have the new actor added to the group the map editor who added it has currently selected.

Author:	*nOssiliconwafer** [ Sat Mar 01, 2014 5:01 pm ]
Post subject:	Re: MapData (in progress...)
sweeeeeet!

Author:	*nOsWildcard** [ Sun Jul 06, 2014 12:40 pm ]
Post subject:	Re: MapData (in progress...)
- 7/1/2014 - Build 94 Picking up the pieces of a project that has been on ice for a long time. Discovered a huge problem involving the amount of time it takes to have al the data written to the .ini file. Now testing to see what functions and phases of capturing MapData takes the most time.

Author:	*nOsWildcard** [ Sun Jul 06, 2014 12:43 pm ]
Post subject:	Re: MapData (in progress...)
- 7/6/2014 - Build 118 I believe I have found a solution to the long time it takes to write the data and have addressed it by redesigning how MapData is going to work by saving data. I have decided that MapData will save as you go every time you add a new actor to the map it will automatically save and it seems to work. The big lag came from trying to save a huge amount of data at once so instead I have it write a little data each time something is added to the map. The only way I'm going to see some lag is if we have a large group of map editors adding tons of stuff simultaneously I mean a lot of stuff in other words the possibility exists for some lag while map data is recording changes to the .ini file on the server but I don't think were likely to experience it. For the first time I got MapData to load all the actors added to a map just like how they were placed in! This is an exciting moment in the project for ultimately this is one of the most important function in the mod. I have a concern however about some lag while loading large amounts of actors however I am confident I can address this with some changes that will make the mod more efficient. Only other problem I see is with the design of the mod. Once actors are written to the MapData .ini files it's kind of totally permanently carved in like a permanent marker. Ultimately this will lead to something NOBODY but the server administrator developer will care about and that is GARBARAGE. That's right garbage. Once map editors start having second thoughts and start removing stuff they added to the map then what will happen all the data is still in the .ini file and what happens is a build up of abandoned actors still sitting in the .ini file and overtime if the map is heavily edited or we have a very indecisive map editor the .ini file will just grow larger and larger... The consequences of this are unknown to me, Luckily however I've seen large .ini files and noticed UT does not care at all not seem to care how large an .ini file which I've seen from my other mods like GauntletStatistics where the file is 2.91 MB in size which is pretty large compared to most other .ini files you'll see in UT but not at big as the old mod that's currently in use that manages loading and saving monsters in a map and its .ini file is 12.98 MB in size! That's huge and that one file contains all the data for every map on the server we added monsters to! My new mod has a lot more chance for bloat however the difference is each map will be stored in it's own separate .ini file. I could go on but as I said to the player this should not matter, I been thinking about ways of recycling data when new objects are added so it reuses the data written already instead of writing more data.

Page 1 of 3	All times are UTC [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/