Leaderboard

Sander added exactly this Bonus immediately with his unit on wall commit.

Then the solution is simple. Every modfolder holds a .json file in which some basic info is listed. The mod manager scans for that file, can't find it (the file wasn't included in A16) and omits the public folder.

Here's the patch for collision detection and as "standalone" as possible: rmgen_collision_detection.diff The entity IDs are stored in the collision grid and are returned if something is to be placed but collides. However, I didn't find a safe and fast way to find the blocking entity by ID (is in g_Map.objects or in g_Map.terrainObjects). So if anyone knows how to do this (without going through the entirety of both lists) or what the IDs are for in the first place, plz let me know. This would be extremely illuminative... EDIT: Like suggested by sanderd17 I'll add a function that can be called with the actor string, the position and the angle to check for collision without actually placing anything (so a temporary abstract object is generated but not placed) However, to generate the obstruction map the collision check has to be called every time an object (with obstruction, checked in the function) was/is about to be placed. It might be better to just log collisions because they are rarely fatal. To know what the entity ID is for would be very nice (in fact vital if e.g. the IDs must be continuous since the above function (as well as not placing "units" because they are blocked by "buildings") will then break things)! The remaining questions are: - What's the entity ID for? - Does the 0.5 m grid catch all units (like e.g. any small chicken)? (It's checked but there might be rarely occurring cases) - How to get an object by ID (For me this seams to need to go through all g_Map.objects and g_Map.terrainObjects and compare the entity ID to their ".id" property which would be horribly slow. If we don't do it too often (the average map contains about 20 collisions) this may still be an option)? A fast solution to find an entity object by it's ID would be not to use "this.objects.push()" to add objects but use "this.objects[entityID] = " and then check for with "if (entityID in g_Map.objects)" (or "if (g_Map.objects.hasOwnProperty(entityID))") and at map export do the same check (and cycle to 150+ undefined objects, yes, but only once so that's OK IMO). Same goes for map.terrainObjects ofc. That's for sure not the cleanest solution but for a clean solution I need to know what the entity ID is supposed to do/ment for!

Proposal for collision detection (THX much Itms for adding template data loading from RMGen): collision_detection.zip ToDo: - Add collision detection for gates - Return the blocking entity IDs (and eventually remove those entities, ATM it just warns then) - Extract the part from Map.addObject() to a standalone function e.g. addObstruction() returning a list of entity IDs it's blocked by - Decide what's to do if something is blocked by something else in general (if such a decision seams reasonable) - ATM it needs quite long to check rectangular objects and (proper) walls are always blocking the adjacent wall parts (So what's to do here?) - Decide what scale to use (ATM it's 1 meter, simulations collision detection is 1/2 meter, terrain tiles/RMGen scale is 4 meters... Larger scale means less precision but faster checks OFC. Scale can simply be changed by changing Map.obstructionGridSizeInMeters) Any ideas welcome!

Proposal for the randomBiome overhaul: randombiome.zip @ Spahbod: We obviously have to find out what you though when you added e.g. '"12-13":Other miscellaneous terrain textures.' and find some more telling names. I'm not sure if I really whant to get involved in this but it would REALLY help if you don't ever dare to add something like this to a RMGEN lib... If it's not ready just keep it in your map and after it is suitable as a lib extract it to a lib... but PLZ not before! (Because otherwise it gets used and the change becomes a lot harder...) So if we find some telling names I will continue ^^. P.S.: IMO the tree actor should only be a temporary solution (This is cause by a bug in the unit and player AI and so it should be fixed there in the end). We really should stop "working around bugs" (no matter if caused in RMGen) so they are noted as those and get fixed.